Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ogicse!unmvax!nmt.edu!nraoaoc
From: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Newsgroups: comp.unix.questions
Subject: Re: removing hard linked directories
Message-ID: <1991Mar21.025311.9821@nmt.edu>
Date: 21 Mar 91 02:53:11 GMT
References: <1991Mar20.013744.12749@ux1.cso.uiuc.edu> <1991Mar20.115508.25638@athena.mit.edu>
Reply-To: rmilner@zia.aoc.nrao.edu (Ruth Milner)
Organization: National Radio Astronomy Observatory, Socorro NM
Lines: 40

In article <1991Mar20.115508.25638@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1991Mar20.013744.12749@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:
>|> How would you recommend removing a directory that is linked under several
>|> different names?  The directory really is empty but rmdir lies and says
>|> it is not empty.
>
>  Well, first of all, perhaps you already know this, but the problem you are
>having is just one of the many reasons why the man pages for ln(1) and link(2)
>say that you shouldn't create hard links to directories.  

(I'm not the poster of the original question, but this just happened to me).

So would somebody please tell me why "mv" will do this?

Scenario: directory in /tmp belonging to someone else. I forget it isn't
mine, come along (just me, not root) and mv it. Result: mv says "not
owner", but by that time it has already created the new directory *and did
not clean it up*. Not nice.

When I did an rm -r on one of them (as root), the contents of both 
disappeared (makes sense), but rm/rmdir would not get rid of the directories.

>  Second, my version of "fsck" automatically deals with hard links to
>directories.  I created the directory /foo on a filesystem and then
>hard-linked /bar to it, and when I ran fsck, got "/bar IS AN EXTRANEOUS HARD
>LINK TO DIRECTORY /foo\n\nREMOVE? "

Guess I'll have to do this single-user manually. The normal multi-user
boot fsck said

  /tmp/baddir2 IS AN EXTRANEOUS LINK TO DIRECTORY /tmp/baddir, IGNORED

>links, unmounting the filesystem and then running "clri" on the inode.  When
>you do this, fsck should be able to clean up.  

Thank you, thank you!
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
                            rmilner@zia.aoc.nrao.edu