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

Previous Next

Full log

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.