[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS
Date: Tue, 14 Feb 2023 11:02:15 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

On 2023-02-14 04:12, Pádraig Brady wrote:

I suspect it's a similar issue to the one that openzfs had:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]