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

[Pádraig Brady]

On 10/02/2023 12:13, George Valkov wrote:
> > On 2023-02-10, at 11:18 AM, Pádraig Brady <P@draigBrady.com> wrote:
> >
> > I'll apply the simple patch later I think.
>
> I have an interesting idea: If I copy a large file, say the 16 GB disk image
> where I compiled OpenWRT. So I copy this on the same filesystem, and check
> disk usage before an after: no change. Also the copy is instant. That’s because
> APFS supports copy-on-write. Initially both files share the same sectors on 
> disk,
> any changes made after that are copied to new sectors.
> This is the most efficient way to copy files on APFS, and should produce no 
> corruption.
> Let’s implement it. I would assume there is a system cal that does the entire 
> copy,
> And we don’t need to read and write any data.
> Does the trace contain any interesting calls that might be related to that?

When you say "I copy a large file", is that with gcp or something else?
Since coreutils 9.1 we try the CoW by default with fclonefileat()
which is available since macOS 10.12 (2016).
Note that works only when src and dest are within the same file system,
but that is the case for you if I'm reading your original report correctly.
When I mentioned that earlier I thought your macOS version was too old to 
support that,
but in fact your 12.6.3 should support fclonefileat() fine.
So that's another variable. Is that call failing completely for you?
You might be quicker to add a couple of printfs around the
fclonefileat() calls in the coreutils from latest git you compliled.
Note there is new error handling related to that call in the latest git,
compared to what was released in coreutils 9.1.
Note also I don't see any fclonefileat() syscalls in your Finder logs at least.

cheers,
Pádraig