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

[C. Gatzemeier]

Welcome back David!

Am Wednesday 01 September 2004 16:43 schrieb David Faure:
> On Monday 30 August 2004 22:18, C. Gatzemeier wrote:

> > [/Trash/A/B/C/datafile]
> > - storage directly usable even witout extra trash tools (CLI)
>
> The proposed .Trash-$uid/files/foo.txt is also usable from the CLI.
> Either manually (you know where you want to move the file to),
> or with a small script that reads it from the info file.
> It would even be simpler to write than "removing files with a deletion date
> from the directory before moving it back", which your solution would need.
> For a given fileid, it would simply have to
> 1) read orig path from info/$fileid
> 2) mv files/$fileid $origpath.
> In any case I suspect that if this spec does become standard, extra
> command-line tools will be developed, since it is rather easy to do.
> Manual command-line usage will be mostly for last-resort recovery.

Ok, point taken, however patching of all (filemanager) tools would be needed 
to browse trash to see original location and date.



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



> > - no known or hidden permission problems
>
> Arguable - it all depends on whether the trash is considered a "private"
> thing or a "possibly shared, when the initial file was shared" thing.
> I still think the latter is a dangerous road, and the trash is basically a
> private thing, so I don't see a problem with .Trash-$uid.

It is sure an option to just say that the trash is private. The question is if 
we really need or should make this assumption recognizing the issues. We 
might not be that far away from a solution though ...



> I think you're missing the complexity introduced by mixing items from
> different dates of deletion into the same directories. From an
> implementation point of view, that approach makes things quite difficult,
> requiring full-depth searches, guessing things from filenames, moving out
> and back in after undeletion of the rest, etc.

I recognize this sort of stuff looks really ugly, nothing we'd want to 
recomend in our spec.

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.

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.

Cheers,
Christian