On 14/02/2023 06:12, Paul Eggert wrote:
> On 2023-02-13 09:16, George Valkov wrote:
>> 1. We apply my original patch to disable sparse-copy on macOS. Otherwise since fclonefileat is not used whenever we overwrite a file, corruption will still occur.
> 
> I'm not entirely sold on this patch, because I still don't understand
> what's happening. The original bug report in
> <https://github.com/openwrt/openwrt/pull/11960> basically says only "it
> doesn't work", and I'd like to know more.
> 
> Part of the reason I'm hesitating is that there are multiple ways of
> interpreting what SEEK_HOLE and SEEK_DATA mean, and perhaps it's just
> that Apple has come up with yet another way to interpret it, which we
> need to know about.

I agree it would be good to know more.
However given it works on HFS but fails on APFS suggests a file system specific issue,
rather than an API mismatch issue (over what we're already catering for on macOS).
I suspect it's a similar issue to the one that openzfs had:
https://github.com/openzfs/zfs/issues/11900

Given how closed / uncommunicative Apple are in general
and specifically for this already reported bug,
I'm inclined to disable SEEK_DATA on __APPLE__ for the upcoming release.

Also we've mitigated the impact somewhat by enabling fclonefileat() in more cases.

> Another reason to hesitate is that GNU coreutils is not the only core
> program that uses SEEK_HOLE and SEEK_DATA. If this really is a generic
> Apple problem we need to know which Apple releases have it, so that we
> can program around it at the Gnulib level instead of mucking about with
> each individual program.

Yes that would be best if possible.

I've attached the 3 latest patches I'm considering in this area.
I presume you're OK with your amended fclonefileat() improvement one?

thanks,
Pádraig