On Nov 15, 2021, at 11:33, Paul Eggert <eggert@cs.ucla.edu> wrote:
Is the source file on a ZFS file system by any chance? See my lseek comment
below.
On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote:
stat64("/tmp/test\0", 0x16DDC36C0, 0x0) = 0 0
fstatat64(0xFFFFFFFFFFFFFFFE, 0x16DDC3C21, 0x16DDC2BA0) = 0 0
fstatat64(0xFFFFFFFFFFFFFFFE, 0x16DDC3C30, 0x16DDC2B10) = 0 0
open("/usr/bin/clear\0", 0x0, 0x0) = 3 0
fstat64(0x3, 0x16DDC2C30, 0x0) = 0 0
open("/tmp/test\0", 0x401, 0x0) = 4 0
fstat64(0x4, 0x16DDC2CC0, 0x0) = 0 0
fstat64(0x4, 0x16DDC2D50, 0x0) = 0 0
fcntl(0x3, 0x32, 0x16DDC3200) = 0 0
fcntl(0x4, 0x32, 0x16DDC2E00) = 0 0
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?
clonefileat(0xFFFFFFFFFFFFFFFE, 0x16DDC3200, 0xFFFFFFFFFFFFFFFE) = -1
Err#18
open("/private/tmp/test\0", 0x601, 0x81ED) = 5 0
close(0x5) = 0 0
open("/private/tmp/test\0", 0x2, 0x0) = 5 0
dup2(0x5, 0x4, 0x0) = 4 0
close(0x5) = 0 0
fchmod(0x4, 0x81ED, 0x0) = 0 0
fchown(0x4, 0x0, 0x0) = 0 0
futimes(0x4, 0x16DDC2DE0, 0x0) = 0 0
sysctl([CTL_HW, 7, 0, 0, 0, 0] (2), 0x207EC4068, 0x16DDC2A30, 0x0, 0x0)
= 0 0
lseek(0x3, 0x0, 0x4) = -1 Err#6
That lseek call looks like OpenZFS bug 11900
<https://github.com/openzfs/zfs/issues/11900>. If you're using ZFS, the bug really
should be fixed in your ZFS implementation as it can affect programs other than coreutils
and there's no easy workaround (other than to disable efficient copying). Is this something
you can look into, or ask someone with macOS and/or ZFS expertise to look into? For more,
see <https://bugs.gnu.org/51433>.
ftruncate(0x4, 0x1D770, 0x0) = 0 0
close(0x4) = 0 0
close(0x3) = 0 0