[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0
Date: Mon, 15 Nov 2021 13:33:44 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]