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.
