GNOME Bugzilla – Bug 766990
multifilesink: 'buffer'-mode writes no longer atomic (regression)
Last modified: 2016-09-30 07:03:37 UTC
f1ceaab02f3f557e23b77b14771a575788f92bb4 changed the behaviour of the file writing. Before the commit, g_file_set_contents was used for the 'buffer' next-file mode of multifilesink. Sample use case: I have a pipeline producing JPEG buffers. I want to store the latest JPEG at a fixed location on the file system, which is exposed by a web server. The latest frame can then be pulled down at a known HTTP URL from another client on the network. With the earlier code that used g_file_set_contents, things worked nicely, as another process (e.g. the web server) reading the file would always have access to a complete buffer, as g_file_set_contents writes to a temporary file, before moving that over to the final destination (it also calls fsync, if necessary). The new code, on the other hand, fwrites directly to the destination file, truncating any existing data, so now there is a race.
Regression, marking as blocker. Lots of people seem to use multifilesink like ... ! jpegenc ! multfilesink next-file=buffer location=last.jpg
Thanks for the bug report, I've reverted the commit now: commit 023998dd76b449440d267d689d578ae3e7a1bdbd Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Sep 27 10:23:38 2016 +0100 Revert "multifilesink: streamline the file-switch code a bit" This reverts commit f1ceaab02f3f557e23b77b14771a575788f92bb4. This broke atomic file writes in "buffer" mode. It did make sure that any streamheaders are prepended to each file in buffer mode as well, but that's not really needed in practice, whereas atomic file writes are, so let's restore the status quo ante for now since this was primarily a code cleanup anyway, and if anyone needs to streamheaders in buffer mode too they can make a patch to implement that differently. Re-implementing the atomic writes in the element also seems way too much work. https://bugzilla.gnome.org/show_bug.cgi?id=766990 commit 6ab88a7f78839e7931afc726d5e8ff42bacf42e1 Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Sep 27 10:22:57 2016 +0100 Revert "multifilesink: close file on write error with next-file mode is set to buffer" This reverts commit 84e441d2685cf223d348a95be0c5ba693bbf6624. This will no longer be needed once we revert f1ceaab02.