Trash mechanism

[Manuel Arriaga]

Hi

Concerning the preservation of file metadata after deletion, I ended
up opting for recreating the user's home directory structure inside
the trash can: ~/personal/resume.pdf will, upon deletion, be put in
~/Trash/personal/resume.pdf. If the user deletes a file outside of her
home, you could just put it in ~/Trash/SYSTEM_ROOT/(absolute path to
file). That allows you to retain the original location/name of the
file. I guess you won't consider it very user friendly, since to
recover a file the user needs to browse the trash can and manually
locate the file she wishes to have back.

As one of you mentioned, preserving time stamps is also easy. On the
other hand, date of deletion is something which, using "regular" file
systems, you you need to log somewhere else.

Offering a "real_unlink()" function could easily be done (it would
just need to dlopen() the original unlink() in glibc), but then again
at this time libtrash only compiles on Linux and your windowing
systems aim at portability.

Good luck,

Manuel


On Wed, 25 Aug 2004 16:08:48 +0200, David Faure <dfaure at trolltech.com> wrote:
> 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).
>