All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pádraig Brady" <P@draigBrady.com>
To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Cc: 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: Sat, 22 Nov 2014 01:29:05 +0000	[thread overview]
Message-ID: <546FE6E1.7040703@draigBrady.com> (raw)
In-Reply-To: <CALCETrW0c1UzkVQgEE_je5BtVhdWRmNaYk4HCQk+t6AWvpC-FA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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?

thanks,
Pádraig.

  parent reply	other threads:[~2014-11-22  1:29 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 [this message]
     [not found]                                 ` <546FE6E1.7040703-V8g9lnOeT5ydJdNcDFJN0w@public.gmane.org>
2014-11-22  1:31                                   ` Andy Lutomirski
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=546FE6E1.7040703@draigBrady.com \
    --to=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=luto-kltTT9wpgjJwATOyAt5JVQ@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.