Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: Re: removing hard linked directories
Message-ID: <1991Mar21.200251.2272@athena.mit.edu>
Date: 21 Mar 91 20:02:51 GMT
References: <1991Mar20.013744.12749@ux1.cso.uiuc.edu> <1991Mar20.115508.25638@athena.mit.edu> <1991Mar21.025311.9821@nmt.edu> <1991Mar21.100031.12027@athena.mit.edu> <8413@mentor.cc.purdue.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 70

In article <8413@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (Bruce Varney) writes:
|> In article <1991Mar21.100031.12027@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
|> }  Staring at the source code for mv on my system, it appears that directories
|> }are moved using an atomic rename system call.  If your mv is behaving as
|> }you've described, then either (a) the rename system call in your kernel is
|> }brain-damaged, or (b) you've got a brain-damaged version of mv.
|> 
|> Some versions of UNIX do not have the rename() call. As such, to do a mv,
|> they implement a link(), then an unlink(). Here is what probably happened. 
|> The / directory was 1777. The mv command was successful up to the link(),
|> but then the unlink() failed because you did not own the directory, and the
|> sticky bit was left on. You were thus left with a hard link to the directory.

  A kernel without an atomic rename operation (or, at least, a rename
operation that tries to be atomic, although it might fail to be completely
atomic in the case of some network filesystems) is, in my opinion,
brain-damaged.  Which is what I said in my original message.  Thank you for
spelling out the particular form the brain-damage takes in this case :-).

|> Johnathan,

  It's Jonathan.

|> 90% of
|> your responses include "this belongs in another newsgroup not this one"'s.

  There are certain cases in which it is clear that articles do not belong. 
Questions about deleting a file whose name starts with '-' or about undeleting
a file, for example, do not belong in comp.unix.wizards.  Questions about
PostScript do not belong in comp.unix.questions (unless they are about using
PostScript under Unix).

|> (although this particular article does not) Just because you think a 
|> certain topic is not appropriate does not mean others don't think it is.

  If you are thinking of a particular case in which I incorrectly said that a
message was inappropriate for a newsgroup, I would like to hear about it, and
I will try not to do that in the future.

  But I do not consider it wrong to tell someone when the post a message in
the wrong newsgroup, nor do I consider it "condescending," and I will continue
to do so.  I will also usually answer the question they asked in addition to
telling them where it should have been posted.  I am going to continue to do
this, so flaming me about it is going to do you little good, and if you want
to do so, I suggest you do it in E-mail and not on the net.

  Incidentally, I have received E-mail from several people who believe that
what I do is a good thing.  To paraphrase you, "Just because you think what
I'm doing is not appropriate does not mean that other people don't think it
is."

|> And in fact, I just got done reading a 30+ line response from you that
|> had 29+ lines of "you could ftp to here for the FAQ, or mail to here, or
|> post to here, or do this" and only one line of help - talk about wasting
|> bandwidth!!!!!!

  The "29+" lines were instructions for getting the FAQ for a newsgroup in
which the FAQ has expired at many sites.  Furthermore, they explained how to
use a new archive server which archives the FAQ's for *every newsgroup*.  That
is certainly not "wasting bandwidth," it is useful information.

  If you want to talk about the issue of rename and the kernel, then I will
continue to do that.  But I will not post any more articles in this thread
about how or what I choose to post.  There is no point to it.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710