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

On 21/11/14 22:40, Andy Lutomirski wrote:

On Fri, Nov 21, 2014 at 2:30 PM, Al Viro [off-list ref] wrote:

quoted

On Fri, Nov 21, 2014 at 10:20:54PM +0000, Pádraig Brady wrote:

quoted

quoted

quoted

That said, would you still like me to take a stab at a proposal to the
POSIX folks that would relax the requirements to allow
implementation-defined behavior when the two arguments to rename
describe the same file but via different directory entries?

I guess there is no point discussing in POSIX and adding extra
implementation options if no implementations do/will act accordingly.

Linux can decide to do that independently, if appropriate.
This is one of those borderline cases where we balance
accretion of cruft vs incompatibility.
On consideration, I'm OK with keeping the existing
rename() behavior for compat and adding the new flag.
That said I still can't think of anything depending
rename() doing nothing with hardlinked source and dest.

You do realize that it opens a very nasty can of worms for filesystems that
are e.g. case-insensitive to some extent?  How do you tell links from
alternative equivalent spellings of the name?

I assume that VFS can handle this correctly if it wants to.

I was assuming there was a way to distinguish directory entries,
and that's what should be checked first, which is what my
psuedo code patch attempted to show.

OTOH, if someone does rename("foo", "Foo"), and foo, Foo, fOO, etc.
are all valid spellings, then presumably they don't actually expect
"foo" to go away.  They may, however, want the name shown in readdir
to change, so maybe RENAME_HARDLINK should do that, too.

That's a separate case, though also useful for case retentive file systems.
If you did want to support that, i.e. when src and dst are the same directory entry,
though spelled differently, then you might have another flag.
Or you could combine both functions to a RENAME_ALIAS flag?

thanks,
Pádraig.