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

[George Valkov]

> On 2023-02-10, at 10:45 PM, Paul Eggert <eggert@cs.ucla.edu> 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