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
