GNU bug report logs - #15926
RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

Previous Next

Package: coreutils;

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

Date: Tue, 19 Nov 2013 11:58:02 UTC

Severity: normal

Tags: notabug, patch

Merged with 15943

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 15926 <at> debbugs.gnu.org
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Thu, 21 Nov 2013 09:55:02 -0800

On 21/11/2013 09:18, Bob Proulx wrote:
> Eric Blake wrote:
>> But that's not what Linda is asking for.  She is not asking to pull "."
>> out of under her feet.
> 
> Actually as I understand it she is expecting the call to succeed if
> the system kernel allows it.  I believe that is the way rm used to
> work before removing '.' was disallowed.
----
Um... I *expect* ".* to be unremoveable.  The entries "." and ".." are
required in all directories.  These are required for a properly structured
directory.   The only way to remove "." and ".." entries in
a directory is to remove the directory name itself:

   rm -fr /tmp/mytmp

would remove mytmp + any contents  (including the structural entries "." and
".." inside 'mytmp' .  However, if I type "rm -fr /tmp/mytmp/." As is implemented
in most OS's, it would do a depth first traversal removal.  At least on linux,
you couldn't remove "." as it is your current position.  You can remove the 
directory
which "." is in as you show below:
> 
>   mkdir /tmp/testdir
>   cd /tmp/testdir
>   rmdir /tmp/testdir
>   echo $?
>   0
>   ls -ldog /tmp/testdir
>   ls: cannot access /tmp/testdir: No such file or directory
>   /bin/pwd
>   /bin/pwd: couldn't find directory entry in ‘..’ with matching i-node


So I expect anything containing "." foo/. to FAIL -- but only AFTER it has already
done depth first traversal.   Adding the "-f" flag was to silence the error and
have the exit code set to '0' due to any failures.

Posix mandates checking "." *first*. when doing a recursive removal with "-f"..

So how about using -F as a gnu extension to ignore that case?

That POSIX would have declared "rm -fr ." illegal on nanny grounds goes against
the original spirit of why the "-f" flag was added in the 1st place.  It meant
to "force" the issue, *if* possible  (if permissions allowed).  I have
no issue with error messages due to permission problems -- as they'd indicate
the directory wasn't "cleaned out" -- "rm -fr ." was to clean out the contents
of a dir to ready it for some reused.

So I propose adding a "-F" to force rm to adhere to its original algorithm and
override the POSIX restriction (as well as serving the purpose of "-f" to
force any removals.


>> Instead, she wants a command that will recursively remove the
>> children of ".", but then leave "." itself unremoved (whether by
>> virtue of the fact that rmdir(".") must fail
> 
> I am missing this part.  Why must it fail?  And in fact as per my test
> case above it succeeds.
----
	you didn't remove "."   You removed the directory "." is
contained in.  A direct removal of "." or ".." should be disallowed
because they are a required part of any directory.  To removed them
you must remove the directory by name, but addressing the structural
entries must fail.





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

Previous Next


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