Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards,net.bugs,net.bugs.usg,net.bugs.v7,net.bugs.2bsd,net.bugs.4bsd
Subject: Re: deleting a bad directory
Message-ID: <1934@rlgvax.UUCP>
Date: Sat, 19-May-84 14:45:21 EDT
Article-I.D.: rlgvax.1934
Posted: Sat May 19 14:45:21 1984
Date-Received: Mon, 21-May-84 03:13:29 EDT
References: <638@sri-arpa.UUCP> <1917@rlgvax.UUCP> <330@vu44.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 17

> Guy said that you could just '/etc/unlink' lost+found. It is
> my experience (Unix v7m) that you should FIRST do an unlink on
> lost+found/. Otherwise fsck finds lost+found before it finds
> lost+found/* , re-links lost+found (into the new lost+found),
> and you still have a problem.

That's why the directions 1) said you should do an "ls -lid" on "lost+found"
to get its inumber and 2) said you should tell "fsck" not to reconnect that
inode when it asks - have it clear it instead.  Unlinking "lost+found/."
and then "lost+found" will work (that removes both links to "lost+found",
and UNIX blows away the inode) unless some of the entries in "lost+found"
are directories - especially the unremovable one; in that case, there will
still be links to "lost+found" (as "lost+found/#blahblah/..") and the inode
will hang around.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy