On 15/11/2021 18:37, Sudhip Nashi via GNU coreutils Bug Reports wrote:
> 
>> 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
> 
> 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.

I saw on other report of failure on macOS.
I think we should disable the SEEK_DATA optimization there for now.
The attached does that.

I'll apply that later.
I also have access to a macOS system, so I'll also test out
if there are ways to use SEEK_DATA there.

thanks,
Pádraig