bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

[Paul Eggert]

On 11/15/21 09:40, Cameron Katri wrote:

> No, this is one APFS (Apple File System).

OK, so ZFS is not involved.


> > > unlink("/private/tmp/test\0", 0x0, 0x0)                = 0 0
> >
> > What's causing this use of "/private/tmp"? I don't see that in the GNU cp
> > source code. Can you put a breakpoint on clonefileat and see what's calling
> > it and what its arguments are?
>
> On macOS, `/tmp` is a symlink to `/private/tmp`.

Fine, but why would 'cp' remove /private/tmp/test when you told it to 
copy to /tmp/test? I see no reason why it would expand the symlink by 
hand, nor why it would remove the destination file even if it calculated 
that /tmp/test and /private/tmp/test were the same file (it's not 
supposed to do that).

And why would 'cp' invoke clonefileat? Coreutils cp's source code does 
not mention clonefileat anywhere.

Something very odd is going on here.

Did you build vanilla coreutils 9.0 yourself? If so, what commands did 
you you use to build it, exactly? If not, who built coreutils and how 
did they configure and/or modify it? I worry that we're looking at a 
version of coreutils cp that has been modified somehow, or that you're 
dtrussing the wrong cp somehow.