Trash specification, version 0.1

[C. Gatzemeier]

> > > 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 
hierarchie)



> 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 
filesystems.

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 
though.

(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.

To handle this more efficiently separate cache could be kept though. See my 
other e-mail.

Christian