On 27.06.2019 10:56, Branko Čibej wrote: > On 26.06.2019 20:57, Branko Čibej wrote: >> On 26.06.2019 18:41, Nathan Hartman wrote: >>> On Wed, Jun 26, 2019 at 11:49 AM Branko Čibej <br...@apache.org >>> <mailto:br...@apache.org>> wrote: >>> >>> On 26.06.2019 04:52, Quentin Smith wrote: >>> > svn_io_file_flush_to_disk in subversion/libsvn_subr/io.c fails to >>> > flush files on AFS filesystems on Darwin. The user-visible >>> experience is: >>> >>> >>> (snip) >>> >>> > The code ignores EINVAL with a comment about filesystems that don't >>> > support it; evidently on Darwin this also needs to include ENOTTY. >>> > >>> > (Also, I suspect it should fall back from fcntl to fsync, since I >>> > suspect fsync /does/ work on AFS filesystems.) >>> >>> >>> (snip) >>> >>> Last but not least, I do wish filesystems were consistent in their >>> implementation ... what on earth is ENOTTY doing here? >>> >>> -- Brane >>> >>> >>> Looks like libuv encountered similar issues and applied similar >>> handling to that in SQLite: >>> >>> https://github.com/libuv/libuv/commit/5b0e1d75a207bb1c662f4495c0d8ba1e81a5bb7d >>> >> Something tell me this should be solved in APR ... > > Turns out that APR is already doing this _almost_ correctly. The kind of > change linked to above would fit in APR quite well. The "problem" is > that Subversion currently doesn't use the "new" APR functions for > sync/datasync. So my suggestion for the fix would be twofold: > > * Enhance the sync functionality in APR (trunk, 1.7 and possibly 1.6) > * Change Subversion to use APR's sync functions > > I'll look into this.
Interesting ... "man fcntl" on macOS does *not* mention ENOTTY at all. So everyone who's currently implementing this fix is relying on an undocumented feature of the filesystem. :) That's fun. -- Brane
