bug-coreutils
[Top][All Lists]
Advanced

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

bug#18499: Possible mv race for hardlinks (rhbz #1141368 )


From: Pádraig Brady
Subject: bug#18499: Possible mv race for hardlinks (rhbz #1141368 )
Date: Wed, 24 Sep 2014 17:18:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 09/18/2014 11:52 AM, Ondrej Vasik wrote:
> Hi,
> 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.

The reason mv does the problematic unlink() is because it needs to simulate
the rename, as rename() has this IMHO incorrect, though defined and documented 
behavior:

  "If oldpath and newpath are existing hard links referring to the same
   file, then rename() does nothing, and returns a success status."

For arbitration of the rename between separate processes,
the kernel needs to be involved.  I noticed the very recent
renameat2() system call added to Linux which supports flags.
Miklos, do you think this is something that could be
handled by renameat2() either implicitly or explicitly with a flag?

thanks,
Pádraig.





reply via email to

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