>In article <Pine.LNX.3.93.960624004545.184G-100000@xarius.demon.co.uk>,
>Darren J Moffat <darren@xarius.demon.co.uk> wrote:
[...]
>>
>>Maybe something better should be done about files in .wastebasket with
>>duplicate names, I've left your solution of adding a version no.
Erm, I may be very wrong here, but shouldn't there be a check on the
length of the name before you append stuff to it ?
Anyone running the patch care to experiment with what happens if you
delete several files with the same 255-character name ?
>How about moving the deleted file into a directory .wastebasket/XXXXX,
>where XXXXX is the inode number of the directory the file was in at
You would still need a version number or something. Also beware - on
large filesystems if .wastebasket is a normal directory you could
easily run up against EXT2_LINK_MAX.
You could get a unique name by using the inode number of the directory
and of the file (if the same name is linked/unlinked to a file then
the same .wastebasket name would be used - no loss there).
Probably want to store deletion time somewhere as well - for purging -
and you can't use dtime in the inode and keep it as a regular file
(well, you could but I think e2fsck will get mad at you for it :).
If the undelete directory is a reserved inode (one is already
allocated for it in the header files) then you could perhaps implement
a psuedo directory structure under /.wastebasket (like /proc), maybe
storing details of deleted names in an expanded dirent with fields for
inode-number-of-directory and deletion-time.
>the moment it was deleted. If that directory has the same permissions
>as the original, you do not even need special tools to undelete or
True - this would also stop things like listing deleted files that you
wouldn't have had permission to list before they were deleted. On the
other hand, if it was a regular directory you would also be able to use
it as such - probably a bad idea.
>"empty trash".. a shell script or perl script will do! Also, this works
>recursively and you can restore everything if you undelete in reverse
>order.
[...]
Only if you also move deleted directories to .wastebasket - which I
don't think this patch does. Note that it also doesn't protect deletion
of a rename() target (it can't since it uses rename itself I think).
ray
--
Ray Auchterlounie Research Student (still) at:
<rda@kythera.demon.co.uk> Signal Processing Group
<rda@eng.cam.ac.uk> Cambridge University Engineering Dept.
"Don't ask me about my thesis (TM)"