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 <brane_at_apache.org
>>> <mailto:brane_at_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
Received on 2019-06-27 11:20:36 CEST