Trash mechanism
C. Gatzemeier
c.gatzemeier at tu-bs.de
Sun Aug 29 23:40:16 EEST 2004
> > 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
More information about the xdg
mailing list