Trash specification, version 0.1
alexl at redhat.com
Mon Aug 30 18:45:23 EEST 2004
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
> 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
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
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
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
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!
More information about the xdg