Date: Sat, 1 Feb 2003 18:07:28 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: bastill@adam.com.au Cc: Bill Moran <wmoran@potentialtech.com>, Lowell Gilbert <freebsd-questions-local@be-well.no-ip.com>, freebsd-questions@FreeBSD.ORG Subject: Re: Ooops. Message-ID: <20030201160728.GB77339@gothmog.gr> In-Reply-To: <1044095023.3e3ba02f81b4b@webmail.adam.com.au> References: <005601c2c8c5$47735b10$6501a8c0@grant> <1043981504.3e39e4c0b6e66@webmail.adam.com.au> <44znpinhl7.fsf@be-well.ilk.org> <1043983614.3e39ecfecd509@webmail.adam.com.au> <20030131201357.GA18381@gothmog.gr> <3E3ADA1B.5020304@potentialtech.com> <1044095023.3e3ba02f81b4b@webmail.adam.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-02-01 20:53, bastill@adam.com.au wrote:
> Quoting Bill Moran <wmoran@potentialtech.com>:
> > I've been quietly following this thread since it started and ...
> > I can't reproduce this behaviour. I've created and deleted I
> > don't know how many test directories and symlinks and I can't get
> > it to do what you're claiming it did.
>
> As root, try copying directory from one disk to another, then rm -rf
> directory from the copy. That seems to be what the two recent
> examples have in common.
I have tried various combinations of ln(1) and rm(1) since the thread
started, and I am sure that there are only two cases where rm deletes
things that the user probably didn't want to remove.
a. Errors in filename completion.
b. Adding a slash (/) character at the end of the link name.
== Case A ==
When completing filenames that start with `.', the Unix shells that I
have tried (/bin/sh and tcsh from the base system, and GNU bash2),
will also match the `..' hard link to the parent directory. This is
dangerous in combination with the -r flag, since rm(1) has no way of
knowing that you don't want to recursively remove the parent directory
and merrily hops along, deleting many more files than the ones you
probably meant, when commands like this are used:
# cd /tmp
# rm -fr .*
I usually get around this foot shooting possibility by avoiding to
delete dotfiles with .* and using the more elaborate, but a lot safer,
pattern .[^.]* to match them:
# cd /tmp
# rm -fr .[^.]*
This makes sure that rm(1) never gets the `..' filename as an argument
and the -r option can't turn around and bite me deleting all the files
on my disk. This will also inhibit rm(1) from deleting files named
with funny patterns like `...hahaha...i.h4x0red.you' so some amount of
care is still required. But deleting less files than necessary is
something I can cope with. Deleting more files than I asked is
something that I always try to avoid :-)
== Case B ==
* Note: When a symlink is suffixed with a slash character, then many
commands that use the fts_xxx() functions in a FreeBSD system will
operate on the *target* of the symlink instead of the symlink itself.
This is clearly apparent in the sample session below:
$ cd /tmp/
$ mkdir test
$ cd test
$ mkdir alpha
$ touch alpha/foo
$ ln -s alpha beta
$ ls -l
total 2
drwxrwxr-x 2 giorgos wheel - 512 Feb 1 17:56 alpha
lrwxrwxr-x 1 giorgos wheel - 5 Feb 1 17:56 beta -> alpha
$ ls -l beta
lrwxrwxr-x 1 giorgos wheel - 5 Feb 1 17:56 beta -> alpha
$ ls -l beta/
total 0
-rw-rw-r-- 1 giorgos wheel - 0 Feb 1 17:56 foo
$ rm -fr beta/
$ ls -l
total 0
lrwxrwxr-x 1 giorgos wheel - 5 Feb 1 17:56 beta -> alpha
$
Note how the last directory listing has beta, still pointing to a
non-existent alpha directory. By calling rm(1) on `beta/' (including
the final slash character) I have explicitly asked that the target of
the link is removed. The link remains, but alpha is deleted.
> The only difference between the two experiences is that I was able
> to remove (eg) the copied bin directory without affecting the
> original, but suffered when trying to remove the copied home
> directory. I assumed (perhaps incorrectly) that the symlink
> attached to home was the cause.
Without having the exact set of commands that you have used, I can't
tell for sure what happened. There are only two cases where the
behavior of commands operating on symlinks might come as a surprise to
the unwary user. Those that I have listed above. I cannot guess
which one of the two bit you and which one bit the original poster of
this thread, without having access to detailed command history though.
> Yes - use tcsh as root.
It's not a matter of the shell. It is a matter of what the arguments
of rm(1) are, when it's used though.
> Unfortunately the history only goes so far back and lots has
> happened since. Sorry. However, I'd be prepared to swear on a
> (small) stack of bibles that the command I issued was:
> rm -rf home
I don't know about swearing, but try as I might I can't get rm(1) to
delete the target of a symlink calling it this way. Add an extra
slash character at the end of that and we're back in territorry that
I can recognise, understand and explain :-)
> This removed /slash/var/home from /dev/ad2 as I wished, but also
> removed the original /usr/home on /dev/ad0. I had RTFM because I
> knew rm was very powerful and that undeletion was "impossible".
> -rf is all that is required to delete a directory and any
> subdirectories therein, is it not?
Yes it is.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030201160728.GB77339>