Trash specification, version 0.1

[Alexander Larsson]

On Mon, 2004-08-30 at 16:30, C. Gatzemeier wrote:
> > > > 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.

Original directory? Where did that ever come into play? The $uid
subdirectory is to get the right permissions for the users trash
directory (so you can write files there, without being publically
readable/writable), and is not in any way related to any 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)

Thats not what i'm talking about at all. What I'm talking about is that
if you have a filesystem with permissions and you use $user as the
trashdir name and move the disk to a system where $user has a different
uid you won't be able to read or write to the users trash directory.

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

I don't understand what you are talking about. What mangling?

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

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

> (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. I just don't see the point of this approach
at all. 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a maverick soccer-playing gangster on the edge. She's a transdimensional 
punk vampire with an incredible destiny. They fight crime!