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

From: George Valkov <[email-masked]>
Date: Fri, 10 Feb 2023 23:35:12 +0200

> On 2023-02-10, at 10:45 PM, Paul Eggert <[email-masked]> wrote:
> 
> On 2/10/23 10:58, Pádraig Brady wrote:
>> I was considering "touch"ing the timestamps after also,
>> but it's better to just maintain them as we're
>> pointing to the same data after all.
> 
> For POSIX conformance we must touch if the user has specified only POSIX options (and has not specified -p).
> 
> And it's not just a POSIX conformance issue. Ordinary users will be surprised if plain 'cp A B' creates a file B with a timestamp from last year.
> 
> Likewise for B's modes.
> 
> There's another complication: recent macOS versions have CLONE_ACL, and we're not using that.

I personally prefer using CoW as default (no parameters), because it is way more efficient:
could save a lot of time and space, especially when long builds or large files are involved.
Of course I also understand that coreutils are expected to meet a certain standard behaviour
among all architectures. Since the source and it’s clone have separate metadata,
it should be possible to change it on the clone, to comply with standards. On the other hand
It feels more natural when the metadata is kept intact for the two files. This is a good
indication that no changes have occurred since the clone or copy, and they are the same.
This approach is also consistent with how macOS Finder copies files and directories:
all metadata is preserved.

Here is a good example: I create a tarball on my OpenWRT router. Extract on the Mac.
Copy to the build directory and create new firmware. This preserves all permissions and
metadata. So there is no need for any special tools or command arguments, it just works.
In this scenario, the permissions are critical to preserve. Timestamp is a good indication of
when the file was last changed, setting a different value on the copy is confusing and makes
it very hard to track which files in a copied directory has changed since.

That’s just my personal opinion for default operation and may not match standards,
but it makes work natural and productive. Command line arguments should be respected.

I found this link in one of the mailing lists you sent, it explains what was wrong
with the original SEEK_DATA and SEEK_HOLE approach on macOS, and why
we can’t relay on them:
https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html

Georgi Valkov
httpstorm.com
nano RTOS