Version: (using KDE KDE 3.2.0) Installed from: RedHat RPMs A useful feature for the trash can would be for it to have an option to purge stuff over a certain age - just as you can for the Trash folder in KMail. e.g. Automatically remove anything over XX days. This saves us the bother of having to review the contents of the trash to see what we're certain we no longer need. This could be easily implemented with a job at startup and/or shutdown which finds old files and culls them.
I agree. It would be nice if the files in the trash could be deleted automatically, for example if : The file is older than x days old The trash can is full (more than x mb in it) (oldest or largest files could be deleted) This would also require a GUI configuration, which should be placed in KControl but which should also be accessible be right-clicking the trash can and selecting "Properties". >This could be easily implemented with a job at startup and/or shutdown which >finds old files and culls them. And/Or when a file is trashed
*** This bug has been confirmed by popular vote. ***
I'd like to emphasize this issue.... Currently we are migrating user directories from one server to another and we discovered a few users having trashcans with about 500MB. Therefore there should be really something like: * a daily notification if there are more than 100MB in your trashcan * or even better an automatic removal after xx days (like it is done with the physical wastbasket in your office room) Just having different icons like proposed by "Bug 54001" is nice, but is is too friendly to solve the problem of (ignorant) users that are not aware of the problem of keeping gigabytes of backup storage for home directories. Please make the "digital trash smell" for users wasting space....
*** Bug 102154 has been marked as a duplicate of this bug. ***
To make it simple I was thinking of implementing - remove the oldest items when the trash becomes bigger than X MB (configurable), until it is again smaller than that size. A possible problem with that, though, is that trashing one big movie would remove all the little files from the trash in one go. But well, this might simply mean that the user made X to small then. The alternative "remove biggest items when trash is bigger than X MB" would lead to immediately deleting the big file (e.g. movie) that was *just* trashed, surely this wouldn't be wanted, right? The alternative "automatically remove anything over N days" is even simpler, but doesn't prevent the trash becoming huge over a single day, and isn't suited for people using rarely their computer. I think the problem that this is all really about is the trash getting too big, not getting too old - right?
I originally asked for this feature so that I wouldn't have to bother culling the trash. My thinking was/is that: 1) If I haven't realised I wrongly deleted something within (say) 28 days, I'll probably never realise. 2) Such a feature would stop me from having to cull the trash (or manually writing a "find" command line!) "Cull after X days" is approximately how real life trash cans work - every week the trash man comes and empties them! So it will lead to least surprising results. "Cull after X days" does mean that huge movie files can lead to temporarily huge trash cans - but in the kind of big installation that Jurgen is talking about, these things will average out; that is, there's only going to be a small number of users with huge files deleted in the last X days. "Cull when bigger than X Mb" could lead to unanticipated problems, depending on your algorithm. If you deleted the biggest files, it could delete what you just trashed, as you point out. If you deleted the oldest files, then one huge file could empty your trash can except for the one file you deleted. Safest and simplest to just go with "delete older than X days". I vote for implementing that, then see if afterwards anyone posts a bug asking for something else.
Presumably people "rarely using their computer" would set the number of days very high? I guess this is just a case of having a sensible default (i.e. not "7 days" - say, something like 70?).
Another problem with "delete over X Mb" is that that will pretty much guarantee you permanently have a trash can of X Mb. For the big installations, that won't work: - Because if X is too big, then it won't solve the problem of too much storage space going on trash. - If X is too small, then you have the "huge file" problem.
*** Bug 108662 has been marked as a duplicate of this bug. ***
See also bug #111861
*** Bug 115710 has been marked as a duplicate of this bug. ***
*** Bug 116080 has been marked as a duplicate of this bug. ***
A Python script has been started at branches/work/kdecleantrash (It is a command line tool, meant for crontabs. Currently it can only do maximal age and maximal size of a file.) To comment #8: a solution can be a minimal age, so that huge files are at least kept for example a few days. Have a nice day!
Age, I hope, in terms of residence in trash, not in terms of file creation?
Reply to comment 13: great to hear that some work is being done on this! Presumably it is planned to integrate this into the GUI at a later point?
On Saturday 12 November 2005 11:14, C.Anne Wilson wrote: (...) > Age, I hope, in terms of residence in trash, not in terms of > file creation? Age compared to the date of the file in trash. So according to the trash specification, it should be the date the file was "trashed". Have a nice day!
Stupid me! I sent the email befoe thinking. :-( Of course the age is compared to the "deletion date" that is part of the data kept beside the "trahed" file. As for the integration into GUI, well, I do not plan it. But the script might be a way to know what features are needed. Currently, I do not plan a GUI because: - I have needed a solution quickly. (My trash directory was overcrowed.) - What GUI should be the target? Only KDE4 is under development now. But a Qt4 only solution would not help KDE3 and any Qt solution would not help any other non-Qt desktop. So I have thought that Python (2.1) would be general enough. - Currently I am missing a solution of what directories should be proceeded. (The "home trash" is easy but the others are not.) But sure a GUI should be perhaps a target, as not every user will want to type "crontab -e" and to edit a crontab entry (not counting to select the right parameters for the script). Have a nice day!
What about a simple configuration gui that will help get the right parameters for a crontab entry? Would that get around the problems? I doubt if there are many directories where you would want to let automatic deletions loose. Maybe some data directories, but building in safeguards against necessary files being deleted sounds difficult. I'd stick to trash until someone shows a need for others.
On Saturday 12 November 2005 14:31, C.Anne Wilson wrote: (...) > What about a simple configuration gui that will help get the > right parameters for a crontab entry? Would that get around the problems? That could be a solution. > > I doubt if there are many directories where you would want to let automatic > deletions loose. Maybe some data directories, but building in safeguards > against necessary files being deleted sounds difficult. I'd stick to trash > until someone shows a need for others. The trash, according to the freedesktop.org specification, has one "home trash" directory per user and can have a user trash directory per partition (and also per user of course). But perhaps the solution is only to parse /etc/mtab to get the current partitions (which I had not thought about before). Have a nice day!
I had the same wish, this is my temporary solution: http://bram85.blogspot.com/2005/11/only-good-for-trash-bin.html . It works fine once put in a cronjob. Note, don't just do a find . -mtime >xx -exec rm -rf {} \; since it will leave some metadata on the harddisk. The script I wrote takes care of that.
Could expiry time be less than a day? Generally speaking, I only need to use trash:/ when I accidentally delete the wrong set of files; then I want to pluck those to safety right away. Therefore an expiry time of half an hour or even less would suit me fine, whereas making the files hang around for even one whole day would make me inclined to just Shift+Delete the file away to begin with (manually emptying trash:/ notwithstanding, since that defeats the purpose of having an autoculler).
This request is now almost 5 years old and apparently really wanted by a lot of people. Many people use a cron job to do that, needs only a few lines of code. It would be good if somebody who understands KDE could have a look if this can be implemented. I can't imagine that it is so difficult, but I know too little about the KDE code to do it. The discussions here about a lot of finer details and special situations are nice but if it isn't implemented what's the point?
Tobias Koenig implemented this for KDE-4.2. "Configure Konqueror" shows a Trash item with the following GUI: [X] Limit to maximum size Maximum size: 10% (983 MByte) When limit reached: Warn Me / Delete Oldest Files From Trash / Delete Biggest Files From Trash. This configuration module is missing in Dolphin though... CC'ing Peter.
Good on Mr. Koenig. However, if one specifically wishes trigger the removal of files from trash:/ based on length-of-stay rather than maximum-size-reached, I suppose one should open a new RFE bug?