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

Previous Next

Full log

Message #17 received at 51857 <at> debbugs.gnu.org (full text, mbox):

From: Cameron Katri <me <at> cameronkatri.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Sudhip Nashi <sudhipnashi <at> icloud.com>,
 Pádraig Brady <P <at> draigBrady.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 12:40:45 -0500

[Message part 1 (text/plain, inline)]

On Mon, Nov 15, 2021 at 09:33:21AM -0800, Paul Eggert wrote:
> Is the source file on a ZFS file system by any chance? See my lseek comment
> below.

No, this is one APFS (Apple File System).

> 
> 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?

On macOS, `/tmp` is a symlink to `/private/tmp`.

> 
> > 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

-- 
Cameron Katri
Email: me <at> cameronkatri.com
PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C

[signature.asc (application/pgp-signature, inline)]

Previous Next

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