From: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
To: "Pádraig Brady" <P@draigbrady.com>
Cc: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Linux FS Devel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: RFC: renameat(): Add a RENAME_REMOVE flag to unlink hardlinks
Date: Fri, 21 Nov 2014 17:31:03 -0800 [thread overview]
Message-ID: <CALCETrX_fLJ22dnASo+Gxt5BsemEnkQY72dZK0vdZ22PfstipA@mail.gmail.com> (raw)
In-Reply-To: <546FE6E1.7040703-V8g9lnOeT5ydJdNcDFJN0w@public.gmane.org>
On Fri, Nov 21, 2014 at 5:29 PM, Pádraig Brady <P@draigbrady.com> wrote:
> On 21/11/14 22:40, Andy Lutomirski wrote:
>> On Fri, Nov 21, 2014 at 2:30 PM, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
>>> On Fri, Nov 21, 2014 at 10:20:54PM +0000, Pádraig Brady wrote:
>>>
>>>>>> 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?
I like that option.
>
> thanks,
> Pádraig.
--
Andy Lutomirski
AMA Capital Management, LLC
next prev parent reply other threads:[~2014-11-22 1:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 14:17 RFC: renameat(): Add a RENAME_REMOVE flag to unlink hardlinks Pádraig Brady
[not found] ` <546F4981.8080907-V8g9lnOeT5ydJdNcDFJN0w@public.gmane.org>
2014-11-21 18:09 ` Andy Lutomirski
[not found] ` <CALCETrXvVxvG+s39v+NMdvfkeb8YjbYjb6UXgDFg5ifYOjeKsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 18:39 ` Pádraig Brady
2014-11-21 19:55 ` Andy Lutomirski
2014-11-21 20:48 ` Pádraig Brady
2014-11-21 21:18 ` Eric Blake
[not found] ` <546FAC18.5020200-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-11-21 21:29 ` Andy Lutomirski
[not found] ` <CALCETrUByDgug68FP=cnj-iwSXvbEEHp=S4a=WhQPFmuKc2pNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 22:20 ` Pádraig Brady
[not found] ` <546FBAC6.6020407-V8g9lnOeT5ydJdNcDFJN0w@public.gmane.org>
2014-11-21 22:30 ` Al Viro
2014-11-21 22:40 ` Andy Lutomirski
[not found] ` <CALCETrW0c1UzkVQgEE_je5BtVhdWRmNaYk4HCQk+t6AWvpC-FA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-22 1:29 ` Pádraig Brady
[not found] ` <546FE6E1.7040703-V8g9lnOeT5ydJdNcDFJN0w@public.gmane.org>
2014-11-22 1:31 ` Andy Lutomirski [this message]
2014-11-22 1:50 ` Al Viro
[not found] ` <20141122015010.GW7996-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2014-11-22 1:51 ` Andy Lutomirski
2014-11-22 1:57 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrX_fLJ22dnASo+Gxt5BsemEnkQY72dZK0vdZ22PfstipA@mail.gmail.com \
--to=luto-klttt9wpgjjwatoyat5jvq@public.gmane.org \
--cc=P@draigbrady.com \
--cc=eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).