Looking to integrate our options (was: Trash specification, version 0.1)
c.gatzemeier at tu-bs.de
Wed Sep 1 19:39:20 EEST 2004
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
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
The full path trashes save us from tempering with permissions or user
More information about the xdg