[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils-bug
Subject:    bug#18499: Possible mv race for hardlinks (rhbz #1141368 )
From:       Pádraig Brady <P () draigBrady ! com>
Date:       2014-09-24 16:18:36
Message-ID: 5422EEDC.80706 () draigBrady ! com
[Download RAW message or body]

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.



[prev in list] [next in list] [prev in thread] [next in thread]