Trash mechanism

[C. Gatzemeier]

> > > 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.
>
> But what if you delete the same file (e.g. B) multiple times? The whole
> point of this trash improvement is to be able to do that. That's what the
> fileid vs filename distinction is for.

When trashing a individual timestamp is added. And on recreation the timestamp 
is striped again, unless a file of that name already exists. All files in the 
trash have the timestamp of the deletion date. (Or we could define that files 
that don't, do inherit the one from their parent directory)



> > 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.
>
> Well, you still need to strip out the date of deletion, as well as the
> additional "id" added to the file in case of multiple files deleted with
> the same name.

I'm not sure, why would we still need an additional id with timestamps?
I don't think the timestamp will pose a problem to the user when manually 
retrieving a file from the trash. It's not uncommon that people put the date 
or version of documents for example into the filename.



> So if your command-line script has to do that, it could just
> as well get the original path from the info/ file and move over the actual
> file from files/, it's actually much simpler than "moving out the files in
> subdirectories that were deleted earlier".

For a script or other kind of program it might sure be easier to use 
meta-data. A user could not as easily browse his /Trash, see where and when 
files came from and copy or move them out manually.

Maybe think similar to the maildir format, programs would generate and use 
indexes users can use the files directly or use a program.

It's not that a desktop trash only format wouldn't allow a different format 
that is nice to browse without a GUI or extra tool.

Isn't the whole point of this conversation that we'd rather like a format that 
is usable and common across UIs?

IMHO it would put up an unfortunate stumbling block that further encapsulats a 
desktop-only experience for users. In things like this there is quite a lot 
of potential to discourage newcomers that just start to explore and learn to 
know their new system.  It may reduce system consistency for the sake of some 
ease in implementation. Maybe what I'm asking is, is that as simple, stupid 
as we can do?



> > BTW wouldn't pooled meta data also produce another permission (listing)
> > problem?
>
> No, because it would go in $topdir/.Trash/$uid/info, so only $uid can
> read it - no listing problem. I think you forgot that we were talking about
> a $uid subdir in non-home trash partitions?

Sorry, for not mentioning it. I see info situation similar as the situation of 
the files.
If we'd pool them into $uid dirs we'd need to have (in some cases redundant) 
meta-data for each possible realm of permissions ($uid, $gid).
Why do we need to create direcories named $uid, $gid or $username at all if 
this data is already part of the filesystems meta-data? (In case the fs does 
not support UIDs etc. ownership is irrelevant or defined during mount time)

If we keep the additional meta data (only the deletion date actually) together 
with the files there would be no fork or risk of divergence. For speed 
reasons DEs could keep a personal cache in the home dir up to date though. Or 
if it should be desired there could be a deamon that keeps a overall current 
cache and answers private queries.



> > There is also a syncing issue, when permissions on the normaly used
> > filesystem are changed possibly when files are recreated from the trash
> > manually.
>
> Like, you lost write access to the directory where the file used to be?
> No problem, you can still drag it to another directory.
> Same thing if the original directory doesn't exist at all anymore.

Ok doesn't seem critical. Other than what you already mentioned, when someone 
restricts permissions to a directory where he previously trashed files from. 
Here in a directory structure resembled during trashing the files are still 
available from the trash.
In case of a later restriction one needs to make sure to delete all previously 
made copies, too anyway. Which is practically impossible. (Released for once 
is released for ever, and changing that wouldn't sound like a good idea to 
me)

I know, you'll probably say the trash will be save in the $topdir/.Trash/$uid 
trash. :)
My concern here is that it wouldn't be right if trashing would by default 
privatize the files beyond what they where before. (Especially /Trashes 
outside of $HOME possibly on shared media)

That's why I'm saying to resemble, for files under /Trash (or /Trash/files) if 
you want, the exact directory and permission structure as where they came 
from under /Trash/..  . A 1:1 permission neutral change, merely "moving out 
of sight".

Under $HOME there is a private directory tree so the tree under /$HOME/Trash/ 
will be private, too. No need to define different rules if we can find some 
universal ones.



> The trash is used in all sorts of creative ways - I've seen people really
> use it as storage, [..]

Thank you for your comments, yeah indeed many interesting uses out there :)

Cheers,
Christian