Looking to integrate our options (was: Trash specification, version 0.1)

[David Faure]

On Wednesday 01 September 2004 18:39, C. Gatzemeier wrote:
> 
> Welcome back David!
Thanks.

> Ok, point taken, however patching of all (filemanager) tools would be needed 
> to browse trash to see original location and date.
There is no such tool yet, since there is no trashcan standard...

> > > - trashing operation purely on filesystem meta-data
> >
> > Hacking information into a filename isn't really "pure" IMHO.
> > What if the user named a file foo.txt[2004-06-04T14:54:00] in the first
> > place? Then the code is going to think that's just metadata and strip it
> > out...
> 
> Only strip out the last timestamp. Right, it't not "pure", just as much within 
> meta-data as you can get without implementing it in the filesystem.

I'm afraid you didn't understand my point. If you have
$trashdir/A[2004-06-04T14:54:00]/B/C/foo.txt[2004-06-04T14:55:00]
then you have no way to know if this is 
1) about a directory named A which was deleted entirely, and which happened to contain a "foo.txt[2004...]" file,
or 
2) about a file named foo.txt which happened to be in a "A[2004...]" directory.
This is what I referred to when saying "guessing from filenames".

> What about the following, possibly there is a way to combine the two things.
> 
> Starting small we keep the trash meta-info/index private, i.e. all under some 
> cache directory in $HOME. The difference now is that it would not only 
> reference a filename but also the location of the trashed file (compared to 
> asuming it resides in ../files). By this we would not introduce that much 
> complexity yet would allow meta-info reconstruction the hard way if things 
> screw up. Or say a future deamon wants to initialize its indexes.

Yes we achieve interoperability if we only specify where the info files are
and not the actual trashed files, but I don't really what we gain from standardizing
on half the job. How does this allow reconstruction? How is this related to a daemon?
In practical terms, where would I put the trashed files then? :)

> The private meta-info could be done as you proposed, or with some other .index 
> and .index.sorted files maybe similar to the maildir spec. (I can't really 
> say anything about this though.) The meta-info/index saves us a lot of the 
> complexity.
> 
> The full path trashes save us from tempering with permissions or user 
> names/uids.

If you're implying that every deleted file (on any partition/device) gets referenced
from some $HOME/.foo/bar directory, then this breaks with removeable devices,
renamed mountpoints etc.
Having a modular solution (where a given device ships all the necessary information,
and uses relative paths) doesn't have those problems (but has others as the thread
showed). However given the trouble Alex has seen with removeable devices,
I gather that we should find a solution that works nicely for those :) - even if that
means a trash system that either copies files to $HOME or requires an admin
to create a .Trash directory. I think this covers both common use cases: home user,
and shared folders in e.g. a company.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).