GNU bug report logs - #61386
[PATCH] cp,mv,install: Disable sparse copy on macOS

Previous Next

Package: coreutils;

Reported by: George Valkov <gvalkov <at> gmail.com>

Date: Thu, 9 Feb 2023 09:36:03 UTC

Severity: normal

Tags: patch

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: George Valkov <gvalkov <at> gmail.com>
Cc: 61386 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS
Date: Sat, 11 Feb 2023 13:53:43 -0800
[Message part 1 (text/plain, inline)]
On 2023-02-10 17:21, George Valkov wrote:

> remember to trace all code paths errors.

Yes, I've been doing that. However, I don't use macOS and the two of us 
are debugging remotely where I write the code and you debug it but 
neither of us know how macOS works. Of course it would be much more 
efficient if we weren't operating with these obstacles, but here we are.

Because the macOS behavior is poorly documented and we lack the source, 
if we can't figure this out fairly quickly coreutils should simply stop 
using fclonefileat because it's unreliable for users and a time sink for 
us. I'm hoping, though, we can get something working with another round 
or two.


> With CLONE_ACL, I get 22 Invalid argument.

OK, this means that although Apple has documented CLONE_ACL and it's in 
your include files, it doesn't work in your version of macOS, because 
either it's not supported by the kernel, or by the filesystem code, or 
by the particular filesystem instance, or for some other reason. EINVAL 
hints that it's the kernel but that's by no means certain.

One possible way to defend against this macOS misbehavior is for cp to 
try to use CLONE_ACL, and if that fails with errno == EINVAL try again 
without CLONE_ACL. I attempted to implement this in the attached patch; 
please give it a try.


> do we want to go the quick route of unlinking the destination and creating a fresh clone?

No, POSIX is clear that plain cp should not unlink and re-create the 
destination. Of course we can add a non-POSIX flag to do that, and we 
already have: cp --remove-destination.
[0001-cp-improve-use-of-fclonefileat.patch (text/x-patch, attachment)]

This bug report was last modified 2 years and 123 days ago.

Previous Next


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