After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796971 - filesink: Implement workaround for some (network) filesystems that spuriously return EACCES on write
filesink: Implement workaround for some (network) filesystems that spuriously...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-08-16 09:10 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 12:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
filesink: Implement workaround for some (network) filesystems that spuriously return EACCES on write (11.48 KB, patch)
2018-08-16 09:10 UTC, Sebastian Dröge (slomo)
none Details | Review

Description Sebastian Dröge (slomo) 2018-08-16 09:10:14 UTC
See commit message
Comment 1 Sebastian Dröge (slomo) 2018-08-16 09:10:20 UTC
Created attachment 373355 [details] [review]
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.

Between write attempts that failed with EACCES we wait 10ms, and after
1000 (10s) consecutive tries that failed with EACCES we simply give up.

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 retry-on-eacces boolean 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.
Comment 2 Olivier Crête 2018-08-20 07:31:40 UTC
Review of attachment 373355 [details] [review]:

That sounds like a workaround very specific to one filesystem? Can you specify which one it is so we can revert it once it's fixed? Are you sure you're not just hitting a kernel bug (and a slightly newer or older kernel would fix it)?
Comment 3 Sebastian Dröge (slomo) 2018-08-27 06:03:52 UTC
(In reply to Olivier Crête from comment #2)
> Review of attachment 373355 [details] [review] [review]:
> 
> That sounds like a workaround very specific to one filesystem? Can you
> specify which one it is so we can revert it once it's fixed? Are you sure
> you're not just hitting a kernel bug (and a slightly newer or older kernel
> would fix it)?

It happens on macOS and Linux, with SMB/CIFS and NFS. So seems more like a general problem unfortunately.
Comment 4 Olivier Crête 2018-08-27 19:43:55 UTC
(In reply to Sebastian Dröge (slomo) from comment #3)
> It happens on macOS and Linux, with SMB/CIFS and NFS. So seems more like a
> general problem unfortunately.

Oh can you add that in a comment then?
Comment 5 Sebastian Dröge (slomo) 2018-08-28 05:53:44 UTC
Sure, will do so when merging if it's otherwise accepted :)
Comment 6 GStreamer system administrator 2018-11-03 12:47:36 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/305.