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

Previous Next

Full log

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)]

Previous Next

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