Re: RFC: renameat(): Add a RENAME_REMOVE flag to unlink hardlinks

On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady [off-list ref] wrote:

If 'a' and 'b' are hardlinks, then the command `mv a b & mv b a`
can result in both being removed as mv needs to emulate the
move with an unlink of the source file.  This can only be done
without races in the kernel and so mv was recently changed
to not allow this operation at all.  mv could safely reintroduce
this feature by leveraging a new flag for renameat() for which
an illustrative/untested patch is attached.

ISTM the issue is that rename(2) does nothing if the source and dest
are hardlinks to each other.  Is that intentional?  I don't see that
behavior as required in the POSIX rename docs.

If we indeed need to keep that behavior around for legacy reasons,
then can we at least give RENAME_REMOVE a better name?

--Andy

thanks,
Pádraig.

-- 
Andy Lutomirski
AMA Capital Management, LLC