Trash specification, version 0.1
c.gatzemeier at tu-bs.de
Mon Aug 30 17:30:04 EEST 2004
> > > The spec says "$topdir/.Trash/user". I'd prefer "$topdir/.Trash/$uid",
> It depends. On centralized systems, the uid is the same. On
> decentralized single user systems the main uid is typically always the
> same (500 on all redhat derivates for instance), which is nice for
> removable devices. It also creates no problem with encoding of the
> filename (the username might have length/characters/whatever not
> representable on the filesystem). Furthermore, on a filesystem with
> permissions saved, even if the usernames and the directory names are the
> same, one cannot use the same trash dir unless the uid is the same,
> because you won't own the trash dir, so with uid as name, we share the
> trashname in exactly the case where it will work.
In that case it wouldn't be necessary to call the directory $uid. You could
call it like the original directory.
The full relevant permissions for a file can not be represented with just the
permissions of only one directory under /Trash and the permissions of the
file itself. (If the original location of the file was deeper than 1 in the
> Of course, in the case of a filesystem without permissions and same
> username but different uids, using the username (if it can be used as a
> directory name on the filesystem) works better.
I don't think user/permission mangling would be something to do for trashing.
IMHO user mappings etc. belogs to the process and policy of mounting
A undelete capable fs would probably basicly (1) internaly flag a
file/direcory as deleted and (2) keep a internal list (meta-data).
For Trashing on top of a fs that might mean:
(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
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.
To handle this more efficiently separate cache could be kept though. See my
More information about the xdg