Trash specification, version 0.1

[C. Gatzemeier]

From the spec draft:
----------------
Such .Trash directories are not in themselves trash storage directories; this 
would break multi-user support. Instead, an $topdir/.Trash directory can 
contain any number of subdirectories, named for users that perform trashing 
operations; i.e. $topdir/.Trash/user . Each of these is a trash storage 
directory, containing the files trashed by this user.
----------------

It may actually rather break multi-user support when dividing trash data. See 
below.


Am Monday 30 August 2004 17:45 schrieb Alexander Larsson:

> > (1) flag -> move
> > Because just flaging files as deleted without fs support does not work,
> > we need to move them aside. Moving /A/B/C/datafile to /Trash/datafile (or
> >  /.Trash/files/datafile) would change the permissions under which
> > datafile is accessible. Moving it to /Trash/A/B/C/datafile can be done
> > 1:1 though.
>

> Why is keeping all this permissions important?
> We store it in the $uid
> subdirectory which is only readable/writable by the user anyway.

Because of just that (the second part of your sentence).  :) Things previously 
deleteable and changeable by more than one person are being privatized. 
Effecitvely permissions are changed yet the "mangling" ;-) The possiblilty 
for other legitimate users to free up diskspace is taken away. I think the 
whole $uid thing outside of $HOME/Trash should be unneccessary. Things could 
work in and outside of $HOME in the same way without the risk of any possible 
permission implications.

>
> > (2) meta-data
> > The only data missing of a file moved to /Trash/A/B/C/datafile is the
> > date of deletion. Here it was proposed to add it as [timestamp] to the
> > filename. This also solves the situation for repeated deletions. There is
> > a speed issue with recursive actions though.
>
> How would you generate a nice trash folder from this though? I doubt
> users want to be forced to navigate the full path of everything they've
> trashed in the trash folder.

By differenciating storage, meta-data/indexing and UI presentation. You can of 
course show a low-volume trash directory with a recursive listing.

Instead of sorting by user during the move part of trashing we can do it 
separately when generating private indexes.


> I just don't see the point of this approach
> at all.

Let's see.
- storage directly usable even witout extra trash tools (CLI)
- trashing operation purely on filesystem meta-data
- no known or hidden permission problems
- same format regardless of $topdir location

Cheers,
Christian