Trash specification, version 0.1
c.gatzemeier at tu-bs.de
Mon Aug 30 23:18:30 EEST 2004
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
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
> > (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.
- 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
More information about the xdg