> either the filesystem maintains the "removed" name in the directory
> structure and marks it in some special way, or the tail
> component-name (pathname?) is stored somewhere else in the filesystem
> and the unremove operation goes there and looks for it.

> if i was changing UFS to implement this stuff i imagine i'd go for
> approach #2.

That might make more sense.  When I thought about this wrt UFS, I was
considering not changing what unlink() did; hence, ununlink() would
search through "extra" directory entry space looking for the name, and
get the inumber from that.  This would mean you'd lose if the directory
space or the inode had been reused, but since I didn't want to touch
the disk format or existing unlink() I felt I had to accept that.  (If
data blocks had been reused, I was imagining a restore with holes where
the reused blocks were, with a warning; the merits of this for general
consumption are debatable, at least.)

> any file remove converts the file to "removed" status.  some cleaner
> process would need to garbage collect whenever free disk space gets
> low.

I would tend to make this part of disk space allocation.  Essentially,
part (most?) of the free disk space actually takes the form of
removed-but-not-resurrected files.  When more disk space is needed, one
of these (the oldest?) is chosen and _really_ removed.

This impairs attempts to do optimal block layout (because the
filesystem is effectively always low on space).  IMO this is not that
much of a problem, because disks that have variable geometry, that
implement bad-block revectoring on their own, and above all multiuser
operations, all pretty much wreck this already.

> that all makes "unremove" a very special operation - not playing the
> standard namespace game at all.  in this case it might well be better
> to have two system calls:
> 	int fd = funremove(const char *pathname)
> which returns an open readonly fd referencing the "removed" file,
(why readonly?)
> and then
> 	int rc = flink(int fd, const char *pathname)
> which takes a file descriptor and links it to the given pathname.

I've wished for flink multiple times already.  (Another call that would
be nice is an open-by-inumber call, but I don't want this to drift off
into a fantasia on everything I've ever wanted in a filesystem :-)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu