GNU bug report logs - #18499
Possible mv race for hardlinks (rhbz #1141368 )

Previous Next

Full log

Message #8 received at 18499 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: ovasik <at> redhat.com, Miklos Szeredi <miklos <at> szeredi.hu>
Cc: 18499 <at> debbugs.gnu.org
Subject: Re: bug#18499: Possible mv race for hardlinks (rhbz #1141368 )
Date: Wed, 24 Sep 2014 17:18:36 +0100

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.