Messages in this thread |  | | From | Mark.Hemment@uniplex ... | Date | Thu, 20 Jun 96 15:19:38 +0100 | Subject | Re: Undelete in user space |
| |
Roger wrote: >> >> On Mon, 17 Jun 1996, Tim Towers wrote: >> [much stuff about user space solutions deleted] > >> You can do it that way, but you can't then have saved files discarded to >> free space, when it's needed.
> 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
|  |