[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#18499: closed (Possible mv race for hardlinks (rhb

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#18499: closed (Possible mv race for hardlinks (rhbz #1141368 ))
Date: Fri, 21 Nov 2014 11:54:02 +0000

Your message dated Fri, 21 Nov 2014 11:53:28 +0000
with message-id <address@hidden>
and subject line Re: bug#18499: Possible mv race for hardlinks (rhbz #1141368 )
has caused the debbugs.gnu.org bug report #18499,
regarding Possible mv race for hardlinks (rhbz #1141368 )
to be marked as done.

(If you believe you have received this mail in error, please contact

18499: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18499
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Possible mv race for hardlinks (rhbz #1141368 ) Date: Thu, 18 Sep 2014 12:52:32 +0200
as reported in https://bugzilla.redhat.com/show_bug.cgi?id=1141368 ,
there is a possible race condition in mv in the case of hardlinks.

Bug is reproducible even on ext4 filesystem (I guess it is filesystem
independent), even with the latest coreutils. There was already attempt
to fix the non-atomicity of mv for hardlinks
( http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12985 ), from
the current reproducer it looks like the fix is probably incomplete.

       Ondrej Vasik

--- End Message ---
--- Begin Message --- Subject: Re: bug#18499: Possible mv race for hardlinks (rhbz #1141368 ) Date: Fri, 21 Nov 2014 11:53:28 +0000 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
On 21/11/14 08:29, Boris Ranto wrote:
> On Fri, 2014-11-21 at 03:30 +0000, Pádraig Brady wrote:
>> We want to leave the logic in place for cp and install though,
>> and I've adjusted your patch accordingly. I've also adjusted
>> the tests to pass and augmented the tests to cover one of
>> the cases missed in the previous patch.  I'll push this tomorrow.
>> thanks,
>> Pádraig.
> Just a note: cp already presented this behaviour before the patch, i.e. 
> cp a b
> on hard links to the same file failed with 
> cp: ‘a’ and ‘b’ are the same file
> On the other hand, install does not present it, it copies over b
> creating new inode for b.

Yep, but there were other cases with `cp -a` with hardlinks
to symlinks, and cp --remove-destination a b.

I've pushed that now.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]