Trash mechanism

[David Faure]

On Wednesday 25 August 2004 15:20, C. Gatzemeier wrote:
> 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 :)

Sorry, I didn't mean that to be offensive. It's certainly the right design for 
the problem it was trying to fix (getting trash functionality everywhere at low cost).
I just don't think ld_preload is the right design for a stable long-term solution.

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

And how would I be able to manually delete core files, from the filemanager,
without sending them to the trash can? Constantly toggling the env. var
from withing the konqueror process itself? Talk about obscure APIs...

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