From owner-freebsd-questions Sat Feb 1 9: 6:43 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AA9C37B401 for ; Sat, 1 Feb 2003 09:06:40 -0800 (PST) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2135D43F75 for ; Sat, 1 Feb 2003 09:06:37 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b172.otenet.gr [212.205.244.180]) by mailsrv.otenet.gr (8.12.6/8.12.6) with ESMTP id h11H6PVq028889; Sat, 1 Feb 2003 19:06:26 +0200 (EET) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.6/8.12.6) with ESMTP id h11H6O9g083354; Sat, 1 Feb 2003 19:06:24 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.6/8.12.6/Submit) id h11G7SJG095489; Sat, 1 Feb 2003 18:07:28 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 1 Feb 2003 18:07:28 +0200 From: Giorgos Keramidas To: bastill@adam.com.au Cc: Bill Moran , Lowell Gilbert , freebsd-questions@FreeBSD.ORG Subject: Re: Ooops. Message-ID: <20030201160728.GB77339@gothmog.gr> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1044095023.3e3ba02f81b4b@webmail.adam.com.au> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2003-02-01 20:53, bastill@adam.com.au wrote: > Quoting Bill Moran : > > 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