GNU bug report logs - #19051
rm symboliclink/ # "Is a directory"

Previous Next

To reply to this bug, email your comments to 19051 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: aaron brick <abrick <at> ccsf.edu>
To: bug-coreutils <at> gnu.org
Subject: rm symboliclink/ # "Is a directory"
Date: Thu, 13 Nov 2014 22:53:09 -0800

hi folks,

$ ln -s / sl
$ rm sl/
rm: cannot remove `sl/': Is a directory
$ rm sl
$

the presence of the slash is not such a great way to test for whether
or not a file is a directory. you may find the above example
contrived, but it occurs easily because bash's default tab completion
for symlinks to directories adds the trailing slash. this confused the
hell out of one of my students.

thanks for your hard work!
aaron brick.

Message #8 received at 19051 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: aaron brick <abrick <at> ccsf.edu>, 19051 <at> debbugs.gnu.org
Subject: Re: bug#19051: rm symboliclink/ # "Is a directory"
Date: Fri, 14 Nov 2014 11:41:57 +0000

tag 19051 notabug
close 19501
stop

On 14/11/14 06:53, aaron brick wrote:
> hi folks,
> 
> $ ln -s / sl
> $ rm sl/
> rm: cannot remove `sl/': Is a directory
> $ rm sl
> $
> 
> the presence of the slash is not such a great way to test for whether
> or not a file is a directory. you may find the above example
> contrived, but it occurs easily because bash's default tab completion
> for symlinks to directories adds the trailing slash. this confused the
> hell out of one of my students.
> 
> thanks for your hard work!
> aaron brick.

Confused me too when I encountered it first, but tt's required by POSIX:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11

But now I see that coreutils rmdir is inconsistent and doesn't
treat sl/ as the directory. We should probably fix that up
to be consistent with other tools, POSIX and other systems.

thanks,

Pádraig.

Message #11 received at 19051 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 aaron brick <abrick <at> ccsf.edu>, 19051 <at> debbugs.gnu.org
Subject: Re: bug#19051: rm symboliclink/ # "Is a directory"
Date: Fri, 14 Nov 2014 06:15:24 -0700

[Message part 1 (text/plain, inline)]

On 11/14/2014 04:41 AM, Pádraig Brady wrote:
> tag 19051 notabug
> close 19501
> stop
> 
> On 14/11/14 06:53, aaron brick wrote:
>> hi folks,
>>
>> $ ln -s / sl
>> $ rm sl/
>> rm: cannot remove `sl/': Is a directory
>> $ rm sl
>> $
>>

> 
> Confused me too when I encountered it first, but tt's required by POSIX:
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11

No, actually, POSIX requires that it (attempt to) remove the DIRECTORY,
not the symlink.  Linux is intentionally in violation of POSIX on this
front.

Try this on Solaris:

$ mkdir a
$ ln -s a b
$ rm b/
$ ls -d ?
b

> 
> But now I see that coreutils rmdir is inconsistent and doesn't
> treat sl/ as the directory. We should probably fix that up
> to be consistent with other tools, POSIX and other systems.

We've had this conversation in the past.  The fact that Linux
intentionally violates POSIX is actually useful; the POSIX behavior
leaves behind dangling symlinks, whereas the Linux behavior makes some
sort of sense (even if not the best quality errno values).  Our decision
has been that we choose NOT to override kernel semantics on this front;
waiting for either the kernel folks to obey POSIX (unlikely) or for
POSIX to relax and concede that the Linux behavior is a useful
alternative and allow it in addition to Solaris behavior (possible, but
I haven't tried pushing hard for it lately).

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

[signature.asc (application/pgp-signature, attachment)]

Message #14 received at 19051 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 aaron brick <abrick <at> ccsf.edu>, 19051 <at> debbugs.gnu.org
Subject: Re: bug#19051: rm symboliclink/ # "Is a directory"
Date: Fri, 14 Nov 2014 07:47:44 -0700

[Message part 1 (text/plain, inline)]

On 11/14/2014 06:15 AM, Eric Blake wrote:

>> Confused me too when I encountered it first, but tt's required by POSIX:
>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
> 
> No, actually, POSIX requires that it (attempt to) remove the DIRECTORY,
> not the symlink.  Linux is intentionally in violation of POSIX on this
> front.
> 
> Try this on Solaris:
> 
> $ mkdir a
> $ ln -s a b
> $ rm b/
> $ ls -d ?
> b

Uggh, serves me right for typing without testing.  I'm mixing up
rename(), unlink(), and rmdir() semantics.  Basically,
unlink("anything/") is required by POSIX to fail because the trailing /
means that the only thing to be removed is a directory, but directories
can only be removed by rmdir(), not unlink().

Still, my point remains when you use 'rm -r b/': on Linux, it fails
(cannot remove 'b/': Not a directory), on Solaris it succeeds at
removing 'a' and leaving 'b' dangling.

The fact that Linux intentionally violates POSIX on some of the corner
cases related to symlinks to directories makes it harder to definitively
state what coreutils should do.

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

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 19051 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, aaron brick <abrick <at> ccsf.edu>, 
 19051 <at> debbugs.gnu.org
Subject: Re: bug#19051: rm symboliclink/ # "Is a directory"
Date: Fri, 14 Nov 2014 14:47:37 +0000

On 14/11/14 13:15, Eric Blake wrote:
> On 11/14/2014 04:41 AM, Pádraig Brady wrote:
>> tag 19051 notabug
>> close 19501
>> stop
>>
>> On 14/11/14 06:53, aaron brick wrote:
>>> hi folks,
>>>
>>> $ ln -s / sl
>>> $ rm sl/
>>> rm: cannot remove `sl/': Is a directory
>>> $ rm sl
>>> $
>>>
> 
>>
>> Confused me too when I encountered it first, but tt's required by POSIX:
>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
> 
> No, actually, POSIX requires that it (attempt to) remove the DIRECTORY,
> not the symlink.  Linux is intentionally in violation of POSIX on this
> front.

Right, that's what I meant. In the original `rm` context above
the directory is (implicitly) referenced.
On all platforms `rm sl/` it will fail.

Following on to the rmdir() issue..
I changed your example below to rmdir which I presume you meant?
Yes solaris leaves the dangling symlink in this case.

> Try this on Solaris:
> 
> $ mkdir a
> $ ln -s a b
> $ rmdir b/
> $ ls -d ?
> b

>> But now I see that coreutils rmdir is inconsistent and doesn't
>> treat sl/ as the directory. We should probably fix that up
>> to be consistent with other tools, POSIX and other systems.
> 
> We've had this conversation in the past.  The fact that Linux
> intentionally violates POSIX is actually useful; the POSIX behavior
> leaves behind dangling symlinks, whereas the Linux behavior makes some
> sort of sense (even if not the best quality errno values).  Our decision
> has been that we choose NOT to override kernel semantics on this front;
> waiting for either the kernel folks to obey POSIX (unlikely) or for
> POSIX to relax and concede that the Linux behavior is a useful
> alternative and allow it in addition to Solaris behavior (possible, but
> I haven't tried pushing hard for it lately).

Thanks for the insight.

So usually a trailing / is treated as the directory itself:

$ mkdir a
$ ln -s a b

$ ls -Fd b/
b//
$ ls -Fd b
b@

$ stat b -c %F
symbolic link
$ stat b/ -c %F
directory

Also in this case coreutils generates that good error internally
without attempting to unlink anything.

$ rm b/
rm: cannot remove ‘b/’: Is a directory

Then we get to the inconsistent Linux behaviour:

$ strace -e unlinkat rm -R b/
unlinkat(AT_FDCWD, "b/", AT_REMOVEDIR)  = -1 ENOTDIR (Not a directory)
rm: cannot remove ‘b/’: Not a directory

$ strace -e rmdir rmdir b/
rmdir("b/")                             = -1 ENOTDIR (Not a directory)
rmdir: failed to remove ‘b/’: Not a directory

I disagree with the inconsistent kernel behavior here,
though agree we shouldn't try to work around it.

thanks,
Pádraig.

Message #20 received at 19051 <at> debbugs.gnu.org (full text, mbox):

From: aaron brick <abrick <at> ccsf.edu>
To: 19051 <at> debbugs.gnu.org
Subject: Re: bug#19051: rm symboliclink/ # "Is a directory"
Date: Fri, 14 Nov 2014 12:23:29 -0800

thanks for your time and comments folks!


On Fri, Nov 14, 2014 at 6:47 AM, Eric Blake <eblake <at> redhat.com> wrote:
> On 11/14/2014 06:15 AM, Eric Blake wrote:
>
>>> Confused me too when I encountered it first, but tt's required by POSIX:
>>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
>>
>> No, actually, POSIX requires that it (attempt to) remove the DIRECTORY,
>> not the symlink.  Linux is intentionally in violation of POSIX on this
>> front.
>>
>> Try this on Solaris:
>>
>> $ mkdir a
>> $ ln -s a b
>> $ rm b/
>> $ ls -d ?
>> b
>
> Uggh, serves me right for typing without testing.  I'm mixing up
> rename(), unlink(), and rmdir() semantics.  Basically,
> unlink("anything/") is required by POSIX to fail because the trailing /
> means that the only thing to be removed is a directory, but directories
> can only be removed by rmdir(), not unlink().
>
> Still, my point remains when you use 'rm -r b/': on Linux, it fails
> (cannot remove 'b/': Not a directory), on Solaris it succeeds at
> removing 'a' and leaving 'b' dangling.
>
> The fact that Linux intentionally violates POSIX on some of the corner
> cases related to symlinks to directories makes it harder to definitively
> state what coreutils should do.
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>

Message #23 received at 19051 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: aaron brick <abrick <at> ccsf.edu>, 19051 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#19051: rm symboliclink/ # "Is a directory"
Date: Fri, 21 Nov 2014 11:39:19 -0800

Eric Blake wrote:
> Still, my point remains when you use 'rm -r b/': on Linux, it fails
----
   (so does 'rm -r b@' as a symlink to a file). 

   The linux way to address the directory has been "rm -r b/." POSIX 
blocked the linux
way of addressing the directory in rm, though, for example, it still 
works in
'cp': "cp -rl b/. a/." correctly makes links in 'a/.' of 'b/.' files.  
But it doesn't see the "." in
a and fail to execute normally.  In fact, attempting that copy isn't 
even an error in 'cp'/,
even though.   "b/." is a symlink to "a/."

   This came up before with symlinked targets and 'rm' and supposedly 
core utils would
always attempt a dir-op with "/" appended, but try a symlink-op w/o it.

Linux is behaving consistently, in that "rm" applies to symlinks, not 
the targets.

On linux to address the content of a directory, "dir/." has generally 
been used, but
as you mention below, POSIX intentionally violated the linux behavior in 
its 2008 update.
I.e. the linux behavior was prsent long before POSIX was changed to 
prevent the linux
addressing strategy

  
> (cannot remove 'b/': Not a directory), on Solaris it succeeds at
> removing 'a' and leaving 'b' dangling.
>
> The fact that Linux intentionally violates POSIX on some of the corner
> cases related to symlinks to directories makes it harder to definitively
> state what coreutils should do.
>   
---
Posix semantics changing away from the original POSIX standard break the 
"portability"
aspect of the POSIX, and, are hard to take seriously as being a 
portability standard when it
can't even maintain standards between it's own versions.  Given the 
relative number of users
of the various *nix's, It sorta looks like POSIX is attempting to wag 
the dog.

I strongly question the logic in linux following some minority standard 
when the largest
user base is likely to be used to the linux behavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.