Trash mechanism

[C. Gatzemeier]

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)
> shouldn't.


> * 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 
all platforms.

Cheers,
Christian