> A deamon can watch the filesystem freespace, and delete
> files from /.wastebasket (using a local copy of the
> unlink system call..... :-) on an as-needed basis.
While trying to keep functionality in user-space is good, this
is one feature that requires file-system (and a little bit of
kernel, and user utility support).
Here's my understanding on how 'versioning' (undelete) support would
work;
When the file-system code performs the unlink(), it does _not_
decrement the inodes count (major point). It simply modifies the
parent directory, such that the reference to the unlinked inode has
a 'special' value.
This 'special' value causes the file-system dependent 'readdir()' et al
to _not_ see this inode any more. Hence it appears removed to
a user performing a, say, 'ls' command.
Using this scheme allows symbolic links, directories, and hard-links
to be unlinked, but still remain present (and intact) on the
file-system.
Whether a user can 'see' deleted files, depends upon a 'flag'. This
is passed to the file-system code, and hey-presto, the undeleted files
can be seen and operated upon in the normal way.
To avoid 'name-space' pollution within a directory (ie. a new file
may have been created with the same name as a delete one), the deleted
files are shown with a ";x" appended (where 'x' is a version number -
sounds like VMS?). This allows for a file, say, "foo" to be created
and deleted multiple times, and each previous version is still
available for undeleting.
To avoid filling a file-system with 'undeleted' files, a few controls
are needed;
1) Max number of versions to keep of a file.
(this is a file-system configurable - can be zero)
2) Are deleted files kept? This is a per-process flag,
kept in the user's task structure. Not all programs
will want/need the ability to undelete files (or admins
will not want some users to be able to do this).
To allow a user to 'see' (ie. operate on ) deleted files would also be
controlled via a flag in the task struct. (Are all access to the
file system always on behalf on a process? Can the process always be
identified?). This flag would be controlled via a system call (does
an appropiate one already exist?).
As the original inode for this file is still around, the ability to
undeleted would be based upon normal UNIX file system permissions.
The 'special' value contained within a directory, which controls the
visibility of a file, is nothing more complicated than renaming the
file. By appending an 'unlikely-to-happend-in-real-life' escape
sequence to the end of the file name in the directory causes it to be
hidden.
Now, renaming a file to hide it does have a few problems. These
are left as an exercise for the reader...they aren't that difficult
to solve (I think...).
The few extra utilites needed might be;
o A purger, to go and _really_ remove all deleted files past
a certain date. (A special option to find, using xargs and
rm?).
o Updated fsck.
o Updated df/du. To allow the blocks/inodes used by
deleted files to be seen.
o A simple utility to turn on/off a users ability to see
deleted files.
May have missed a few details here, but does the reasoning sound
firm?
markhe