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

Previous Next

Full log

Message #14 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>, Pádraig Brady
 <P <at> draigBrady.com>
Cc: Sudhip Nashi <sudhipnashi <at> icloud.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 09:33:21 -0800

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

Previous Next

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