Sebastian Dröge eec9bd8db3 filesink: Implement workaround for some (network) filesystems that spuriously return EACCES on write ... This seems to happen when another client is accessing the file at the same time, and retrying after a short amount of time solves it. Sometimes partial data is written at that point already but we have no idea how much it is, or if what was written is correct (it sometimes isn't) so we always first seek back to the current position and repeat the whole failed write. It happens at least on Linux and macOS on SMB/CIFS and NFS file systems. Between write attempts that failed with EACCES we wait 10ms, and after enough consecutive tries that failed with EACCES we simply time out. In theory a valid EACCES for files to which we simply have no access should've happened already during the call to open(), except for NFS (see open(2)). This can be enabled with the new max-transient-error-timeout property, and a new o-sync boolean property was added to open the file in O_SYNC mode as without that it's not guaranteed that we get EACCES for the actual writev() call that failed but might only get it at a later time. Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/305		2019-05-16 14:15:02 +03:00
..
elements	filesink: Implement workaround for some (network) filesystems that spuriously return EACCES on write	2019-05-16 14:15:02 +03:00
tracers	tracer: latency: Don't compare element name as element Id is already unique	2019-04-15 11:29:32 +00:00
Makefile.am	gsttraceutils: actually disable tracing system hooks if configured	2017-11-24 13:40:34 +01:00
meson.build	Port to hotdoc	2019-05-13 16:34:09 -04:00