> On Nov 15, 2021, at 11:33, Paul Eggert <egg...@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
Turns out lseek is broken (or at least works differently) on macOS as well
(https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). Funny
coincidence! I’ll take a better look later this week if I can and try to see
what the exact problem is.
