Trash mechanism

[Mike Hearn]

> 1) Garbage collectable somehow.
> - IIRC, Windows does this.

It pops up a modeless dialog asking you if you want to empty the trash 
can in low disk space conditions.

> 2) Take up minimal space when it's used. (Like, say, by compressing the 
> files.)
> - IIRC, Windows does this.

No clue ....

> Oddly, I think Windows does this largely right - it even indicates quite 
> clearly to the user whether they're deleting the file or not. (It takes 
> up 99% of the CPU by doing so with an animation, but hey.)

Well, a basic trash concept isn't especially complicated. In an era of 
such huge disks it seems silly to actually delete files when there's 
plenty of disk space left to use up but at the same time bolting a 
transparent trashcan onto pre-existing software is really difficult.

This is especially true as mostly you only delete files from the file 
manager. We can always use libtrash as a personal thing if we want rm to 
do the same. David and Alexander are right, it's a matter of agreeing on 
the contents and locations of the trash folders. Anything fancier than 
file manager integration can come later.

> I think we can do better, mind:
> 
> a) We can use preloads to handle write() returning ENOSPC in order to 
> recover diskspace and repeat the write(), potentially.

Any widespread use of preloads to achieve desktop functionality is 
embarassing as it basically means we are overriding the glibc team, 
which makes it look like we can't keep our house in order. Due to the 
nature of ELF fixup it's also a bit dangerous, you can easily override 
things you didn't mean to.

> [*] - A British term meaning "whoops"

I'm a brit too, mind ;)