After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 108413 - The trash bin should empty automatically
The trash bin should empty automatically
Status: RESOLVED DUPLICATE of bug 341722
Product: nautilus
Classification: Core
Component: Trash
2.2.x
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 303156 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-03-14 21:53 UTC by Nicolás Lichtmaier
Modified: 2006-10-27 11:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Nicolás Lichtmaier 2003-03-14 21:53:14 UTC
This has just happened to an user here:

He wanted to copy something to an empty floppy disk and there was a "disk
full error". After some investigation I've found out that it was the trash
directory in the floppy disk.

This shouldn't have happened! The trash should nevere make a normal
operation to fail with "disk full". There should be a configurable
percentage with the maximun use the trash directory can use!

This is a polich and usability issue (specially for newbie users).
Comment 1 Matthias Warkus 2003-08-15 14:27:51 UTC
There should be some sensible threshold such as 5% or 10% of the size
of the filesystem $HOME is on at which Nautilus warns about Trash
overfill in a *nonintrusive* way.
This does not mean to display a warning window just once (user will
forget) or everytime you move something into Trash (annoying). It
could mean adding a warning notice such as "Your Trash is very full.
You might want to delete part or all of it permanently." to the Trash
properties window and to the transfer window displayed when moving
something to Trash. Perhaps it should also offer you a button to clean
out everything  in the trash older than 30 days or such.
Completely emptying the trash can should never be necessary because
the most recent deletions should always stay on hand.
Comment 2 Vincent Noel 2004-08-27 16:59:53 UTC
*** Bug 149572 has been marked as a duplicate of this bug. ***
Comment 3 Vincent Noel 2004-08-27 17:01:14 UTC
Bug 149572 suggests that files in the trash older than i.e. 3 months should be
automatically deleted.
Comment 4 Jaap A. Haitsma 2004-08-27 18:18:30 UTC
NOTE in comment 3 i.e. should be e.g.
Comment 5 Matthew Paul Thomas (mpt) 2005-04-27 16:44:46 UTC
A "configurable percentage" won't solve the original problem 100% of the time.
Neither will a "sensible threshold". And neither will automatically deleting
stuff from the Trash over a certain age (though that would be extremely nifty).

The only OS I know of that solved this particular problem 100% of the time was,
I regret to say, Mac OS Classic.
 ___________________________________________
|:::::::::::::::::::::::::::::::::::::::::::|
|  ,                                        |
| /!\  There is not enough room on the disk |
| """  "Mark's Stuff" to copy the selected  |
|      items, unless you empty the Trash.   |
|      Do you want to empty the Trash now?  |
|                                           |
|                     ( Cancel ) ((  OK  )) |
|___________________________________________|

(The Mac OS X Finder isn't as smart; it just says there's not enough space.)
Comment 6 Sebastien Bacher 2005-05-18 07:38:39 UTC
*** Bug 303156 has been marked as a duplicate of this bug. ***
Comment 7 Sven J. 2005-06-19 23:09:12 UTC
Dialog in #5 shows a good idea, but could be improved by a algorithm that
deletes only as much files in the trash as needed - starting with the oldest.
Comment 8 John Nilsson 2005-11-27 22:21:48 UTC
Is it possible to just mark files as "trashed" and request that disk space is
(re)claimed by the OS by oldes entry first, as needed?
Comment 9 Alexey Rusakov 2006-05-22 05:00:06 UTC
I'm a maintainer of GNOME for ALT Linux distribution, and I have received multiple complaints about this behaviour recently. I believe that such a behaviour makes working with floppies, USB flash drives, cards etc. quite troublesome. If a user doesn't care about the Trash (which is often true), he/she can use the space of a media only once. I'm afraid, the significance of this bug is underestimated.
The idea from comment 8 looks good to me but needs a lot of work and is prone to troubles, as we have a command line and file managers other than Nautilus. A dumb fix for the problem would be to switch off Trash for some kinds of media. When a user deletes data from such media, he gets a warning as for the permanent deletion. Although I'm not sure it is the best solution, it is relatively easy to do.
Comment 10 sdiconov 2006-05-22 13:31:17 UTC
I can confirm this bug. It is very annoying to erase Trash when you are in a hurry.

I would like the Trash contents to be deleted automatically without any useless dialogs if the media has too little space and if it really helps to free up enough space to perform the requested operation. 

I would also like to have a set of options to control Trash behaviour, such as 
1) turning off Trash for floppies and small flash drives and 
2) an option to delete small files to HDD Trash instead of floppy trash. If the file to be deleted is less then 1Mb, as many text and office documents are, it can be easy enough to copy it to HDD trash transparently and permanently delete it from the media. Caching can smooth the performance loss.

Comment 11 tom 2006-06-04 19:40:34 UTC
I'd either:

1. turn off trash for all devices <x GB, or for removeable devices at all.

or

2. when you copy a file to an external drive, and there's not enough space left _because of the trash folder_ then the trash folder should just be deleted - optionally with a warning dialog like shown above.

Tom
Comment 12 André Klapper 2006-10-19 21:32:15 UTC
sounds more like bug 341722 to me

*** This bug has been marked as a duplicate of 341722 ***
Comment 13 Matthew Paul Thomas (mpt) 2006-10-27 11:47:14 UTC
Bug 341722 is one possible solution, but not necessarily the best solution, to this bug. (And this bug was reported three years earlier.)