GNU bug report logs - #56391
`cp --reflink=always` creates empty file on failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56391 in the body.
You can then email your comments to 56391 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Benjamin Gilbert <bgilbert <at> backtick.net>
To: bug-coreutils <at> gnu.org
Subject: `cp --reflink=always` creates empty file on failure
Date: Tue, 5 Jul 2022 01:39:11 -0400

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

Hi,

When `cp --reflink=always` fails because the filesystem does not support
reflinks, I'd expect it not to leave anything at the destination path.
However, it appears to leave an empty file instead:

$ ls -l
total 0
$ echo "some data" > src
$ cp --reflink=always src dest
cp: failed to clone 'dest' from 'src': Operation not supported
$ ls -l
total 4
-rw-rw-r--. 1 bgilbert bgilbert  0 Jul  5 01:27 dest
-rw-rw-r--. 1 bgilbert bgilbert 10 Jul  5 01:27 src

I'm seeing this on both coreutils 9.0 (Fedora 36) and 9.1.31-fa332 built
from Git.

Best,
--Benjamin Gilbert

[Message part 2 (text/html, inline)]

Message #12 received at 56391-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Benjamin Gilbert <bgilbert <at> backtick.net>
Cc: 56391-done <at> debbugs.gnu.org
Subject: Re: bug#56391: `cp --reflink=always` creates empty file on failure
Date: Tue, 5 Jul 2022 10:04:48 -0500

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

Thanks for reporting that. I installed the attached patch.

[0001-cp-don-t-create-empty-file-if-cannot-clone.patch (text/x-patch, attachment)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: 56391 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, bgilbert <at> backtick.net
Subject: Re: bug#56391: `cp --reflink=always` creates empty file on failure
Date: Wed, 6 Jul 2022 12:17:22 +0100

On 05/07/2022 16:04, Paul Eggert wrote:
> Thanks for reporting that. I installed the attached patch.

This will usually work, but there are cases where this may lose data,
as previously discussed at:

https://bugzilla.redhat.com/show_bug.cgi?id=921708
http://lists.gnu.org/archive/html/coreutils/2013-03/msg00056.html

I'm not sure cp can robustly clean up in this situation?

cheers,
Pádraig

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: bgilbert <at> backtick.net, 56391 <at> debbugs.gnu.org
Subject: Re: bug#56391: `cp --reflink=always` creates empty file on failure
Date: Wed, 6 Jul 2022 14:48:33 -0500

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

On 7/6/22 06:17, Pádraig Brady wrote:
> This will usually work, but there are cases where this may lose data,
> as previously discussed at:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=921708
> http://lists.gnu.org/archive/html/coreutils/2013-03/msg00056.html
>
> I'm not sure cp can robustly clean up in this situation? 

Thanks for pointing me to those old discussions. As I understand it, the 
worry is that FICLONE will only partly succeed, causing the destination 
file to contain some (but not all) the input data, and then if we remove 
the output file we'll lose the newly-made partial clone. I don't know 
whether FICLONE can do that, but it sounds like a reasonable worry.

If that understanding is correct, then the attached further patch should 
suffice, so I boldly installed it.

[0001-cp-don-t-remove-nonempty-cloned-dest.patch (text/x-patch, attachment)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bgilbert <at> backtick.net, Fridolin Pokorny <fpokorny <at> redhat.com>,
 56391 <at> debbugs.gnu.org
Subject: Re: bug#56391: `cp --reflink=always` creates empty file on failure
Date: Thu, 7 Jul 2022 16:39:44 +0100

forcemerge 56391 56392
close 56391
stop

On 06/07/2022 20:48, Paul Eggert wrote:
> On 7/6/22 06:17, Pádraig Brady wrote:
>> This will usually work, but there are cases where this may lose data,
>> as previously discussed at:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=921708
>> http://lists.gnu.org/archive/html/coreutils/2013-03/msg00056.html
>>
>> I'm not sure cp can robustly clean up in this situation?
> 
> Thanks for pointing me to those old discussions. As I understand it, the
> worry is that FICLONE will only partly succeed, causing the destination
> file to contain some (but not all) the input data, and then if we remove
> the output file we'll lose the newly-made partial clone. I don't know
> whether FICLONE can do that, but it sounds like a reasonable worry.
> 
> If that understanding is correct, then the attached further patch should
> suffice, so I boldly installed it.

Yes that's better thanks.
The code looks good, and should cater for any issues
within a single cp instance.

As for overlapping processes accessing a file, this may introduce
new edge cases for where a file will be deleted. But I don't see
a specific issue with that, given there are existing truncation
races etc. with overlapping access to a file.  I haven't thought
through all scenarios TBH.

marking this as done.

thanks!
Pádraig

Previous Next

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