Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!munnari!kre
From: kre@munnari.UUCP
Newsgroups: comp.bugs.sys5
Subject: Re: Unlinking "."
Message-ID: <1502@munnari.oz>
Date: Fri, 10-Apr-87 18:55:36 EST
Article-I.D.: munnari.1502
Posted: Fri Apr 10 18:55:36 1987
Date-Received: Sat, 11-Apr-87 20:52:26 EST
References: <1059@cci632.UUCP> <5715@brl-smoke.ARPA> <736@killer.UUCP> <753@killer.UUCP>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 19
Keywords: unlink

In article <753@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes:
> I don't
> know if you paid any attention to the discussion about trashed file names,
> but it seems to me that a system call that won't let you unlink a directory
> with file entries in it is going to prevent the usual fix to this problem -
> unlink the directory and run fsck(1).
> 

Beats me what kind of trashy fsck you have if you think this will
achieve anything, with any reasonable fsck at all, what you've just
described is a pretty slow way to do ...

	set -- `ls -id $dir`
	mv $dir /.../lost+found/#$1

That is, upon finding an unlinked directory, fsck will simply relink
it into lost+found, all the files in it remain as they were.

kre