GNU bug report logs - #51857
cross-filesystem copying broken on macOS with coreutils >= 9.0

Previous Next

Full log

Message #23 received at 51857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Cameron Katri <me <at> cameronkatri.com>
Cc: Sudhip Nashi <sudhipnashi <at> icloud.com>,
 Pádraig Brady <P <at> draigBrady.com>, 51857 <at> debbugs.gnu.org
Subject: Re: bug#51857: cross-filesystem copying broken on macOS with
 coreutils >= 9.0
Date: Mon, 15 Nov 2021 13:33:44 -0800

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.