Subject: bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

From: Pádraig Brady <[email-masked]>
Date: Wed, 15 Feb 2023 09:43:51 +0000

On 14/02/2023 19:02, Paul Eggert wrote:
> On 2023-02-14 04:12, Pádraig Brady wrote:
> 
>> I suspect it's a similar issue to the one that openzfs had:
>> https://github.com/openzfs/zfs/issues/11900
> 
> Yes, quite likely.
> 
> 
>> 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.
> 
> If there's an imminent release that's the only way to go. However, if we
> do that we should also disable fclonefileat since the latest edition of
> the patch isn't right either. It messes up the modes in some cases and
> there's a good reason we don't otherwise allow writing through dangling
> symlinks (see the length email discussions when that was put in) so that
> would have to be addressed too.
> 
> I'll see if I can come up with an improved version of the fclonefileat
> patch that would handle these issues.
> 
> 
>> I've attached the 3 latest patches I'm considering in this area.
>> I presume you're OK with your amended fclonefileat() improvement one?
> 
> Not yet, because it doesn't work correctly in some cases (e.g.,
> x->explicit_no_preserve_mode) and it mishandles the dangling symlink cases.
> 
> The dangling symlink patch might be OK; depends on how fclonefileat
> patch ends up. It's OK to copy through a dangling symlink with
> fclonefileat only if we don't need to fix up permissions or timestamps
> afterwards (e.g., cp -p).
> 
> The disabling SEEK_HOLE on Apple is OK if a release is imminent.
> Otherwise I'd like to get to the bottom of it first. This can be done by
> having George use dtrace or (if that's not possible) adding debugging
> printfs.

Cool.
The release is 1 - 2 weeks away anyway.

thanks for looking at this Paul.

Pádraig