Non Destructive Version of rm

[David Dick]

In <1991May3.212619.21119 at casbah.acns.nwu.edu> navarra at casbah.acns.nwu.edu (John 'tms' Navarra) writes:

>In article <11283 at statware.UUCP> mcf at statware.UUCP ( Mathieu Federspiel) writes:

[description of a renaming scheme for tentative file removal elided]

[desc. of tentative-removal directory scheme elided]

These two schemes seem to have their own advantages and disadvantages.

Renaming (prefixing filenames with something special-- ".#" was suggested)
has the advantage of leaving files in place in their filesystem
hierarchy, but reserves a class of names in the namespace, and
makes scavenging for too-old files slow (because the whole filesystem
must be searched).

Moving (copying the files with their original names into a fixed
directory) has the advantage of preserving original names and 
not cluttering up the namespace, but full-path information is lost
and collisions of filenames can still occur.

How about a .deleted sub-directory in any directory where one
of these commands has been used?  Then a tentatively-deleted file
can be moved there (very efficient, since only linking and unlinking
is necessary), the original name can be used, and full-path information
is preserved.  The scavenger still needs to do a full filesystem search,
but I don't think it should be continuously running, anyway.

One additional thing that these schemes need, however hard it may be
to provide, is emergency deletion.  That is, just as Macintosh
wastebasket contents get reclaimed if more blocks are needed, it
would be really nice if the same thing could happen, automatically,
if a filesystem ran out of space.  On most bigger machines, this is 
of little concern.  But, for individual systems, barely scraping by,
this could be a real life-saver.

David Dick
Software Innovations, Inc. [the Software Moving Company (sm)]