On Fri, Nov 21, 2014 at 10:39 AM, Pádraig Brady <P@xxxxxxxxxxxxxx> wrote: > On 21/11/14 18:09, Andy Lutomirski wrote: >> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@xxxxxxxxxxxxxx> 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. > > It's surprising and annoying that existing systems do this, > but they're conforming to the wording of POSIX I thinkg as > it says that rename() does nothing when the source and dest > _file_ is the same. What POSIX really meant I suppose was _file name_. > Eric, perhaps an adjustment could be proposed to POSIX, as I can't > see anything relying on the current behavior? Which Eric? --Andy > >> If we indeed need to keep that behavior around for legacy reasons, >> then can we at least give RENAME_REMOVE a better name? > > Definitely not attached to the name :) > Let's see if we can change it without a flag, though I guess > that would mean that mv on older systems would > silently do nothing in this case. > > thanks, > Pádraig. > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
