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

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

[Pádraig Brady]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

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.

thanks,
Pádraig.

[-- Attachment #2: renameat_REMOVE.patch --]
[-- Type: text/x-patch, Size: 2618 bytes --]

>From 26d552617b00b3ffcd3b4646467cab5cb02f33ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <P@draigBrady.com>
Date: Fri, 21 Nov 2014 14:09:54 +0000
Subject: [PATCH] renameat: Add RENAME_REMOVE flag to unlink source if hardlink
 to dest

This operation can't be done in userspace with unlink without races,
as overlapping rename operations could remove both hardlinks.
---
 Documentation/filesystems/vfs.txt |  1 +
 fs/namei.c                        | 11 +++++++----
 include/uapi/linux/fs.h           |  1 +
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 20bf204..2daa41a 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -430,6 +430,7 @@ otherwise noted.
 	(2) RENAME_EXCHANGE: exchange source and target.  Both must
 	exist; this is checked by the VFS.  Unlike plain rename,
 	source and target may be of different type.
+	(4) RENAME_REMOVE: unlink source even if a hardlink to dest.
 
   readlink: called by the readlink(2) system call. Only required if
 	you want to support reading symbolic links
diff --git a/fs/namei.c b/fs/namei.c
index db5fe86..caed596 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4074,8 +4074,10 @@ int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
 	bool new_is_dir = false;
 	unsigned max_links = new_dir->i_sb->s_max_links;
 
-	if (source == target)
-		return 0;
+	if (source == target) {
+		if (old_dentry == new_dentry || !(flags & RENAME_REMOVE))
+			return 0;
+        }
 
 	error = may_delete(old_dir, old_dentry, is_dir);
 	if (error)
@@ -4210,10 +4212,11 @@ SYSCALL_DEFINE5(renameat2, int, olddfd, const char __user *, oldname,
 	bool should_retry = false;
 	int error;
 
-	if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE | RENAME_WHITEOUT))
+	if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE |
+		      RENAME_WHITEOUT | RENAME_REMOVE))
 		return -EINVAL;
 
-	if ((flags & (RENAME_NOREPLACE | RENAME_WHITEOUT)) &&
+	if ((flags & (RENAME_NOREPLACE | RENAME_WHITEOUT | RENAME_REMOVE)) &&
 	    (flags & RENAME_EXCHANGE))
 		return -EINVAL;
 
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 3735fa0..601d901 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -38,6 +38,7 @@
 #define RENAME_NOREPLACE	(1 << 0)	/* Don't overwrite target */
 #define RENAME_EXCHANGE		(1 << 1)	/* Exchange source and dest */
 #define RENAME_WHITEOUT		(1 << 2)	/* Whiteout source */
+#define RENAME_REMOVE		(1 << 3)	/* Remove source hardlink */
 
 struct fstrim_range {
 	__u64 start;
-- 
2.1.0

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

[Andy Lutomirski]

On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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

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

[Pádraig Brady]

On 21/11/14 18:09, Andy Lutomirski wrote:
> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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?

> 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.

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

[Andy Lutomirski]

On Fri, Nov 21, 2014 at 10:39 AM, Pádraig Brady <P@draigbrady.com> wrote:
> On 21/11/14 18:09, Andy Lutomirski wrote:
>> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pádraig Brady]

On 21/11/14 19:55, Andy Lutomirski wrote:
> On Fri, Nov 21, 2014 at 10:39 AM, Pádraig Brady <P@draigbrady.com> wrote:
>> On 21/11/14 18:09, Andy Lutomirski wrote:
>>> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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?

The one I forgot to CC :/

thanks,
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 3129 bytes --]

On 11/21/2014 01:48 PM, Pádraig Brady wrote:
> On 21/11/14 19:55, Andy Lutomirski wrote:
>> On Fri, Nov 21, 2014 at 10:39 AM, Pádraig Brady <P@draigbrady.com> wrote:
>>> On 21/11/14 18:09, Andy Lutomirski wrote:
>>>> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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.

Yes, POSIX unfortunately requires that behavior:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html

"If the old argument and the new argument resolve to either the same
existing directory entry or different directory entries for the same
existing file, rename() shall return successfully and perform no other
action."

>>>
>>> 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?

The POSIX wording describes existing practice of all implementations,
and as annoying as it is, requiring all implementations to change would
be too invasive, and going against that wording without the use of an
extension to renameat would catch software off-guard that is expecting
the baked-in POSIX semantics.

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?  Note that I
am NOT proposing a change to rename("a", "a") which must always succeed
(true even when two spellings are different but still resolve to the
same directory entry, as in rename("a", "./a")).  Rather, this is only a
question about the behavior of rename("a", "b") when they are two
different hardlinks resolving to the same file.

At any rate, regardless of what POSIX says, I'm totally in favor of a
renameat flag that gives us fine-tune control over the behavior; we can
implement it now as an extension, and once it hits mainline kernel, I
would have no problems proposing that flag for POSIX standardization
(the POSIX folks have a thing for preferring existing implementations,
after all)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

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

[Andy Lutomirski]

On Fri, Nov 21, 2014 at 1:18 PM, Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 11/21/2014 01:48 PM, Pádraig Brady wrote:
>> On 21/11/14 19:55, Andy Lutomirski wrote:
>>> On Fri, Nov 21, 2014 at 10:39 AM, Pádraig Brady <P@draigbrady.com> wrote:
>>>> On 21/11/14 18:09, Andy Lutomirski wrote:
>>>>> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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.
>
> Yes, POSIX unfortunately requires that behavior:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
>
> "If the old argument and the new argument resolve to either the same
> existing directory entry or different directory entries for the same
> existing file, rename() shall return successfully and perform no other
> action."
>
>>>>
>>>> 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?
>
> The POSIX wording describes existing practice of all implementations,
> and as annoying as it is, requiring all implementations to change would
> be too invasive, and going against that wording without the use of an
> extension to renameat would catch software off-guard that is expecting
> the baked-in POSIX semantics.
>
> 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?  Note that I
> am NOT proposing a change to rename("a", "a") which must always succeed
> (true even when two spellings are different but still resolve to the
> same directory entry, as in rename("a", "./a")).  Rather, this is only a
> question about the behavior of rename("a", "b") when they are two
> different hardlinks resolving to the same file.
>
> At any rate, regardless of what POSIX says, I'm totally in favor of a
> renameat flag that gives us fine-tune control over the behavior; we can
> implement it now as an extension, and once it hits mainline kernel, I
> would have no problems proposing that flag for POSIX standardization
> (the POSIX folks have a thing for preferring existing implementations,
> after all)

renameat has no flags -- this would be renameat2.  Standardizing that
might be quite nice (at least the RENAME_NOREPLACE part).

My two cents: the new flag could be RENAME_HARDLINKS.

--Andy

>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

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

[Pádraig Brady]

On 21/11/14 21:29, Andy Lutomirski wrote:
> On Fri, Nov 21, 2014 at 1:18 PM, Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 11/21/2014 01:48 PM, Pádraig Brady wrote:
>>> On 21/11/14 19:55, Andy Lutomirski wrote:
>>>> On Fri, Nov 21, 2014 at 10:39 AM, Pádraig Brady <P@draigbrady.com> wrote:
>>>>> On 21/11/14 18:09, Andy Lutomirski wrote:
>>>>>> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> 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.
>>
>> Yes, POSIX unfortunately requires that behavior:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
>>
>> "If the old argument and the new argument resolve to either the same
>> existing directory entry or different directory entries for the same
>> existing file, rename() shall return successfully and perform no other
>> action."
>>
>>>>>
>>>>> 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?
>>
>> The POSIX wording describes existing practice of all implementations,
>> and as annoying as it is, requiring all implementations to change would
>> be too invasive, and going against that wording without the use of an
>> extension to renameat would catch software off-guard that is expecting
>> the baked-in POSIX semantics.
>>
>> 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.

>> Note that I
>> am NOT proposing a change to rename("a", "a") which must always succeed
>> (true even when two spellings are different but still resolve to the
>> same directory entry, as in rename("a", "./a")).  Rather, this is only a
>> question about the behavior of rename("a", "b") when they are two
>> different hardlinks resolving to the same file.
>>
>> At any rate, regardless of what POSIX says, I'm totally in favor of a
>> renameat flag that gives us fine-tune control over the behavior; we can
>> implement it now as an extension, and once it hits mainline kernel, I
>> would have no problems proposing that flag for POSIX standardization
>> (the POSIX folks have a thing for preferring existing implementations,
>> after all)

+1

> renameat has no flags -- this would be renameat2.  Standardizing that
> might be quite nice (at least the RENAME_NOREPLACE part).
> 
> My two cents: the new flag could be RENAME_HARDLINKS.

+1

thanks guys!
Pádraig.

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

[Al Viro]

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?

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

[Andy Lutomirski]

On Fri, Nov 21, 2014 at 2:30 PM, Al Viro <viro@zeniv.linux.org.uk> 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.

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.

--Andy

-- 
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pádraig Brady]

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.

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

[Andy Lutomirski]

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

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

[Al Viro]

On Sat, Nov 22, 2014 at 01:29:05AM +0000, Pádraig Brady wrote:

> > 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.

There isn't, in general.  Sure, if you get the same struct dentry * from
both lookups, it's the same one.  But it's not guaranteed to be true on
every fs out there if those are non-directories (and for directories there's
no multiple hardlinks in the first place).

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

[Andy Lutomirski]

On Fri, Nov 21, 2014 at 5:50 PM, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
> On Sat, Nov 22, 2014 at 01:29:05AM +0000, Pádraig Brady wrote:
>
>> > 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.
>
> There isn't, in general.  Sure, if you get the same struct dentry * from
> both lookups, it's the same one.  But it's not guaranteed to be true on
> every fs out there if those are non-directories (and for directories there's
> no multiple hardlinks in the first place).

Does that mean that the current behavior is inconsistent between filesystems.

-- 
Andy Lutomirski
AMA Capital Management, LLC

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

[Al Viro]

On Fri, Nov 21, 2014 at 05:51:23PM -0800, Andy Lutomirski wrote:
> On Fri, Nov 21, 2014 at 5:50 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Sat, Nov 22, 2014 at 01:29:05AM +0000, Pádraig Brady wrote:
> >
> >> > 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.
> >
> > There isn't, in general.  Sure, if you get the same struct dentry * from
> > both lookups, it's the same one.  But it's not guaranteed to be true on
> > every fs out there if those are non-directories (and for directories there's
> > no multiple hardlinks in the first place).
> 
> Does that mean that the current behavior is inconsistent between filesystems.

No.  You can always check that they point to the same inode.  Which is
precisely what "links to the same file" is about, and which is why rename(2)
had that semantics since way back.  _That_ is easy condition to check.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html