c.gatzemeier at tu-bs.de
Wed Aug 25 16:20:52 EEST 2004
Am Wednesday 25 August 2004 14:28 schrieb David Faure:
> On Wednesday 25 August 2004 14:10, C. Gatzemeier wrote:
> > Am Wednesday 25 August 2004 13:05 schrieb Mike Hearn:
> > > LD_PRELOADed libraries can be useful but we need better infrastructure
> > > in order to deploy them as part of a desktop system (in particular,
> > > some way to mark binaries as having particular libraries preloaded).
> > Yeah, I had simmilar doubts. But after reading libtrash readme I found it
> > quite reasonable. Libtrash already takes several measures. When preloaded
> > it checks for environment variables that can control its behaviour for
> > example.
> I don't see libtrash as a reasonable solution for the needs of
> desktop-level trash functionality, for two reasons:
> * Bad design
(Well, let's first look at it a little more relaxed :)
> Changing the meaning of low-level glibc calls is not only fragile, it's
> also unflexible. How would one be able to ensure that manually-deleted
> files from /tmp that could be important to the user get to the trash, but
> temp files from compilation don't?
By running konqueror or whatever user's filemanager with
GLOBAL_PROTECTION = YES I guess.
> The proper solution is to let the
> low-level calls do what they always did, and let the user-level
> applications (GUI apps and fileutils tools) use the trash functionality,
> while other programs deleting files (like gcc for the case of object files)
> * Lack of metadata information
> We need a proper trash abstraction with metadata associated to the deleted
> files (including date of deletion, original mtime, original location),
> of which libtrash only provides the third one.
Yes, a clear subject for collaboration.
> As always: let's try to standardize on the behavior, not necessarily on the
> code. If we come up with a reasonable standard for this, libtrash can
Exactly, and not only because it might not be possible to preload libtrash on
More information about the xdg