filesink: continue element cleanup even if fclose fails

Sometimes filesink cleanup during stop may fail due to fclose error.
In this case object left partial cleanup with no file opened
but still holding old file descriptor.

It's not possible to change location property in a such state,
so next start will cause old file overwrite if 'append' does not set.

According to man page and POSIX standard about fclose behavior(extract):
------------------------------------------------------------------------
The fclose() function shall cause the stream pointed to by stream
to be flushed and the associated file to be closed.
...
Whether or not the call succeeds, the stream shall be disassociated
from the file and any buffer set by the setbuf() or setvbuf()
function shall be disassociated from the stream.
...
The fclose() function shall perform the equivalent of a close()
on the file descriptor that is associated with the stream
pointed to by stream.

After the call to fclose(), any use of stream results
in undefined behavior.
------------------------------------------------------------------------

So file is in 'closed' state no matter if fclose succeed or not.
And cleanup could be continued.

https://bugzilla.gnome.org/show_bug.cgi?id=757596
This commit is contained in:
Anton Bondarenko 2015-11-05 08:56:43 +01:00 committed by Sebastian Dröge
parent ca22e60b91
commit f468eb7db0

View file

@ -439,7 +439,8 @@ gst_file_sink_close_file (GstFileSink * sink)
{
if (sink->file) {
if (fclose (sink->file) != 0)
goto close_failed;
GST_ELEMENT_ERROR (sink, RESOURCE, CLOSE,
(_("Error closing file \"%s\"."), sink->filename), GST_ERROR_SYSTEM);
GST_DEBUG_OBJECT (sink, "closed file");
sink->file = NULL;
@ -447,15 +448,6 @@ gst_file_sink_close_file (GstFileSink * sink)
g_free (sink->buffer);
sink->buffer = NULL;
}
return;
/* ERRORS */
close_failed:
{
GST_ELEMENT_ERROR (sink, RESOURCE, CLOSE,
(_("Error closing file \"%s\"."), sink->filename), GST_ERROR_SYSTEM);
return;
}
}
static gboolean