From owner-freebsd-hackers Wed Apr 10 0:29:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 3FC8D37B417 for ; Wed, 10 Apr 2002 00:29:15 -0700 (PDT) Received: from pool0121.cvx40-bradley.dialup.earthlink.net ([216.244.42.121] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16vCXS-0004i5-00; Wed, 10 Apr 2002 00:29:07 -0700 Message-ID: <3CB3E9A4.7DE79AA1@mindspring.com> Date: Wed, 10 Apr 2002 00:28:36 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bogdan TARU Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 'rm' incompatibility with Posix.2 References: <20020410091302.Y79904-200000@fw.cgn.icom> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bogdan TARU wrote: > As you can see, when I tried to remove the symlink 'b' with a trailing > slash 'rm -rf b/', the target directory was removed instead of the actual > symlink. Of course, this is weird (tryied it on some other 10 un*xes, and > all worked in another way). > > I have attached a patch for the 'rm' untility, which strips the trailing > slash(es) from the path (according to Posix.2). But I think there are many > other utilities which need to be patched (e.g. cp, mv). The trailing "/" is supposed to be this way. It means "evaluate the preceeding as a directory". This is a kernel thing: it's what makes "ls -l symlink-to-dir" show the symlink, and "ls -l symlink-to-dir/" show the contents of the directory pointed to by the symlink). You will also notice that when you are tab-expanding a symlink to a directory in tcsh (now csh), that it automatically adds the trailing "/"... in fact, if I had to guess, this is where I would expect that you had seen the behaviour. For a recursive removal of a symlink or a directory containing a symlink, this makes sense, actually, since the idea of recursively removing something you can't recurse into *doesn't* make sense. If you were going to patch this at all, the only thing that *might* make sense is to do an lstat() before deciding to recurse into the thing. Notice that an lstat on "symlink-to-dir/" acts like stat; while without the trailing "/", it does not. This also reinforces the correctness of the behaviour. Are you maybe using an alias which expand to "rm -rf $*"?? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message