GNU bug report logs - #12339
Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Mon, 3 Sep 2012 00:34:02 UTC

Severity: normal

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: "Linda A. Walsh" <law <at> tlinx.org>
To: Jim Meyering <meyering <at> redhat.com>,
	"12339 <at> debbugs.gnu.org" <12339 <at> debbugs.gnu.org>,
	Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: [PATCH] rm: avoid bogus diagnostic for a slash-decorated
	symlink-to-dir
Date: Tue, 04 Sep 2012 10:46:10 -0700
Jim Meyering wrote:
> These commands would evoke an invalid diagnostic:
>     $ mkdir d && ln -s d s && env rm -r s/
>     rm: cannot remove 's': Too many levels of symbolic links
> remove.c was stripping trailing slashes from "s/" before passing
> the name to "rm".  But a trailing slash may change the semantics,
> and thus should not be stripped.
>   
I would assert that the trailing "." shouldn't be stripped either.

If the directory is a mount point -- then "." would indicate the
contents of the mount point -- being after the "/", while the "/" would be
the mount point itself.

In my case, I wanted to delete everything in the mount point.  Removal
of the mount point itself would ideally unmount the 'fs', but I won't hold
my breath on that one (and leave the root inode of the file system in 
the unmounted file system -- thus I've effectively removed "." from 
mountpoint/.
Which is different from the "." of a directory entry -- NO I'm not
asking for this as a feature, I'm just saying it would be a valid semantic
paradigm").  I WOULD want rm dir foobar/. to remove all contents in the 
directory before failing on ".".  The original version of posix didn't have
this restriction/problem.   POSIX is portability standard -- it should not
be regarded as a restrictive standard, unless not doing so would hinder 
portability.  In effect, they are disallowing OS's to make extensions beyond
what they allow in the newer standards... 

That goes WAY beyond a portability standard...






This bug report was last modified 6 years and 187 days ago.

Previous Next


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