Trash

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



John Nilsson wrote:
> On Mon, 2005-11-28 at 05:22 +0200, Sandis Neilands wrote:
> 
>>And if you want to delete older files first how would you determine
>>how long the file is in trash? Touching it before/right after moving
>>to trash is a bad idea, because in case you decide to restore the file
>>it's timestamps should be modified again.
> 
> 
> This would obviously require some kernel support. Which means that it
> won't be implemented in gnome (portability).
> 

What the heck are you babbling about?

~/.trashdb -- List of s*$t that's in the trash and information about it

Don't kernel everything, this isn't windows.  There's no need for kernel
support for a function of an application.

> Files wouldn't be moved anywhere, just simply flagged as deleted, and
> have a deletion date attribute. Maybe extended attributes can be used?
> The interesting part is how to index them for quick access...
> 

I'd say theoretical ~/.trashdb would have a list of files et. al. (buddy
list items from GAIM can exist too, etc) that are being deleted, and
where they originally were, and where they are now; they'd be moved to
.Trash/ in the directory that they were in and possibly renamed.

This list would then carry the date and time the files were deleted, as
well as their size.  This would be used to make quick decisions about
how to clear or restore files.

The .Trash/ directories could be .Trash.UID/ to keep different users out
of eachothers' trash; however, having similar permissions to the parent
directory would be preferable.  This may not always be possible, as in
the case with root:teachers 770; however, maintaining group and world
permissions is usually sufficient.

As for how to clear the trash, leave that manual by default.  Offer the
user the ability to have trash delete objects when his quota or disk
space is unreasonably low, with the following options:

 - Minimum quota/disk left (default 100M or 1%; incriments of 1M or 0.1%)
 - Minimum time objects must be in the trash (default 1 day)
 - Delete objects based on first trashed
 - Delete objects based on deleting the [biggest/smallest] first
 - Avoid deleting objects that haven't been trashed for a minimum period
of time (default 7 days)

This would allow configurations such as:

 - Items can be deleted if they reside on a disk with less than 150M
free space; Items will only be deleted if they were trashed more than 36
hours ago; Bigger items will be deleted first; the biggest item may be
left if it was trashed less than 5 days ago and a smaller but sufficient
item was trashed earlier.

 - Items can be deleted if less than 2.5% of the disk is free; items can
be deleted after 15 minutes; delete the smallest items first.

 - Items can be deleted if less than 4% of the disk is free; items can
be deleted immediately; delete the first trashed item first.

It may be worth having a system-level trash daemon for multi-user
systems to get CAP_FOWNER.  This would allow trash management to span
across all users, even users not logged in; as well as handle the odd
permission issues for files accessible by multiple users.  For
low-quota, the user would have the ability to delete any files owned by
him, even those trashed by other users.  Of course low-quota would have
to be responded to by deleting files that affect the quota; no use
deleting /home/user/X when /home/shared/ is running low on quota for the
user.

> This kind of system redesign might be overkill for Ubuntu. But then
> again, why not?
> 
> Regards,
> John
> 
> 
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiznehDd4aOud5P8RAi4aAJ49IfcpnoGPSN2y0SbNRUjP7u7IogCfRUBS
kKGoJOGS49fA5EdvbPoZviY=
=28uW
-----END PGP SIGNATURE-----