Limit the size of the trash-bin in KDE3?

[Duncan]

Anne Wilson posted on Wed, 09 Sep 2009 19:09:09 +0100 as excerpted:

> With today's large disks space is rarely an issue.  What _is_ an issue
> is that our memories become less reliable as we get older.  I use Delete
> if I'm absolutely sure I want rid of it, but otherwise I use Trash.  I
> feel reasonably confident that if I haven't needed it 7 days later I'm
> not going to need it again, and it will be automatically deleted.

That's an interesting point you bring up.  I'm 42, so in theory time 
should be starting to catch up to me (I know that while I'm near-sighted, 
if I wear my contacts with full distance correction, I need reading 
glasses for small print now).

But... I don't think the 7-day thing would be useful, here.  When I see a 
file, it's either something I want to keep, or not.  There's seldom a 
"might I want it later" question at all.  Where there is, say for old 
config files that I'm not sure whether they're still used or not 
(generally in $HOME since nearly everything system-side is easy enough to 
check for ownership against the package database), as you said, disk 
space isn't generally a big issue any more, and I sort of create my own 
"trash" by renaming the file/directory to "*.remove".  Then the next time 
I happen across it, which might be a month later or a year later, I'll 
actually remove it.  So far I've a good enough memory that if I come 
across it in the next few days, I remember tagging it with the .remove, 
and think "Oh, that wasn't long enough to know yet" and just ignore it.  
But if worse comes to worse and I can't remember it any longer, I can 
check the times and see.  If the dates are sufficiently old, it's safe to 
remove.

But I think part of it has to do with one's comfort level with their 
filesystem layout as well.  I've always had little use for locate and 
friends, and now for this "semantic desktop" stuff, because file tree 
layout has always been intuitively logical to me, and I can normally find 
stuff in the file hierarchy without an issue.  Even if I don't know 
specifically what file I'm after, I usually know it's in one of two or 
three places in the file tree, and can either go there and look, or go 
there and use mc's file-search functions or grep or whatever, on a small 
enough data subset that real-time searches return in just that, real-
time, or close enough it doesn't matter.  So the time and space wasted by 
keeping an index upto date is a serious enough bother for low enough 
return that it's simply not worth it to me, and I always turn that stuff 
off.  (That my schedule is varied enough that there's no reliable time I 
could set for the database update, and be confident it wouldn't interfere 
with what I was doing a couple weeks from now when I'm actually using the 
computer at that time, is another big negative discouraging automated 
index use.)

So part of the problem with an automated trash for me is that it then 
removes data from its "proper" location in the file tree, putting it in a 
different location, that to me is "improper".  If I'm using it, there's a 
proper location for it and I want to be able to find it there.  If I'm 
not using and not going to use it in the foreseeable future, the "proper" 
location is /dev/null, -- delete the thing!  If there's some question, 
then there's still a "proper" location for it, the usual location but 
with that .remove rename, so it's still easily found.  If I *DO* need it 
later, I wouldn't intuitively go look in the trash for it, I'd go look in 
it's proper location, using tab-completion in the shell or browsing to it 
in mc or whatever, and immediately see that .remove tag on it and recall 
thinking it might not be needed, and doing that to test it.  So a trash 
folder is an unwanted imposition on my own filesystem management, since 
anything located there isn't in its "proper" location, where I know where 
it is or that it's gone, but in some unintuitive location, in an 
unintuitive state, perhaps still there, perhaps fully deleted.  That 
unintuitive location and state BOTHERS me, and I take a serious dislike 
to any automated trash scheme for that reason.

But as they say, different strokes for different folks.  People with a 
sufficiently lower geek factor evidently find both big indexing databases 
and automated "keep it safe for awhile" trash schemes much more useful 
than I do.  That's fine for them and as long as I can turn it off without 
too much trouble, I don't have a problem with it either.  But what I hate 
is when there's no "reasonable" way to turn it off and get the "trash" 
options out of my face, on the context menu and the like, or if it can be 
done, but that removal doesn't "stick", that is, the stupid things keep 
coming back at every update, undoing my toolbar and option 
customizations, etc, as KDE has had a tendency to do in the past.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.