Trash mechanism

[C. Gatzemeier]

> > hmm, thought with the date "attached" we could spare us the separate meta
> > info file tree if a file is moved to a trash subdirectory that
> > corresponds to its original location.
>
> This doesn't work. Without meta info, if you delete A/B and later on A
> itself, and then you restore A, it's going to come up with a strange
> "A/B[dateofdeletion]" file in it,

Yes, unless the date is striped or better the file is correctly not moved out 
because the deletion date preceeds the one of the requested undo action.

> since that file was actually there in the
> trash. Plus, listing the deleted files and dirs requires a recursive search
> and heuristics based on the filename (!).

That would be the cost of an implementation that would work without any extra 
metadata (unlikely?). But a trash directory like this would be logicaly 
usable even from the comand line or other filemanagers without any special 
undo tools.

The separate meta data could be created from such a format like an index 
anytime though, or not?

BTW wouldn't pooled meta data also produce another permission (listing) 
problem? Requireing a deamon?

There is also a syncing issue, when permissions on the normaly used filesystem 
are changed possibly when files are recreated from the trash manually. I 
guess live with it or use a fs that has true undelete feature? Are those some 
of the things that can't (reasonably) be solved on this high level? 

BTW 2 how do you think the trash is mostly used? I for one tend to use it only 
against accidential deletion. So my trash is really rather small, most of the 
time. I don't think I keep any trash for longer than a week ;-)

Cheers,
Christian