> In article <960624485.104553@drinkel.cistron.nl>
> Miquel van Smoorenburg <miquels@cistron.nl> wrote:
>
> >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 ?
yes, but this was never meant to be the full solution :-)
> Anyone running the patch care to experiment with what happens if you
> delete several files with the same 255-character name ?
At a guess the name, would get truncated by ext2fs and would probably
result in an infinite loop in the fs code.
I'm working on an alternative solution at the moment, one which would
allow an unrm program to retreive stuff from the current directory.
> >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
Why would we still need a version number ? Since only one file of any
name could ever exist in a directory then using the inode number of the
directory it lived in makes it unique anywhere in the fs.
If you are suggesting that we keep past versions of files with the same
name from the same directory eg.
$ rm ~/tmp/foo --> .../.wastebasket/1234/foo
$ vi ~/tmp/foo
$ rm ~/tmp/foo --> .../.wastebasket/1234/foo_1
$ unrm ~/tmp/foo
UX: unrm multiple files exist please specify version number
-rw------- 1 darren staff 3969 Jul 5 17:59 foo
-rw------- 1 darren staff 1237 Jul 5 18:00 foo_1
$ unrm ~/tmp/foo -v 1
This is something completely diffrent, ie a snapshot or versioning
filesystem - which I think Linux should have.
I recon that a snapshot fs could be implemented by a userlevel daemon
(maybe with a wee bit of help from the kernel) but versioning would
require a full fs.
> large filesystems if .wastebasket is a normal directory you could
> easily run up against EXT2_LINK_MAX.
.wastebasket would be a normal directory. <linux/ext2_fs.h> has the
following declaration:
#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */
I'm not sure what the intention was with this, I can only assume that
somesort of mkwastebasket util similar to mklost+found was intended.
As for the LINK_MAX why would we be using links ? when a file gets
unlinked then it is moved to the .wastebasket directory.
> 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).
Assuming only the last copy of a file is kept then inode and filename is
good enough.
> 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 :).
I think e2fsck should be taught about .wastebasket as being special in
anycase.
> 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.
This sounds like it might have potential, but could get very complex very
quickly. I'd like to keep undelete as small as possible it has a better
chance of getting accepted by Linus et al.
> >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).
Exactly right, this is something I'm looking at presently, since the
patch was no better than an aliases rm that checked and removed the +u
attribute.
-- Darren J Moffat