Version: (using KDE KDE 3.5.8) Installed from: SuSE RPMs Here is what happened yesterday -- I tried to delete file using gwenview and I couldn't with message "not enough free disk space". It appeared that actually it was impossible to create any new file and since Trash uses two files per each one file user can get into situation that she/he cannot delete anything and in order to delete something she/he has to delete someting. Sounds recurrent? It is a design flaw. Maybe those additional info files in Trash are not necessary for deleting files, that way problem would be solved right away (btw. deleting files should be 0-penalty, currently it not only takes more space than deleted file but adds another file).
On Friday 23 November 2007, Maciej Pilichowski wrote: > Maybe those additional info files in Trash are not necessary for deleting files Those files are necessary when listing the trash contents and for the restore feature, we cannot trash a file without that info. So yes, it's not 0-penalty, trashing a file means creating a new .trashinfo file, this is how it was specified together with freedesktop.org, I don't plan on changing that now... (but I'm ready to admit that this small downside of the chosen solution wasn't really foreseen, maybe we should have used a single info file to at least minimize the changes of this happening). > in order to delete something she/he has to delete someting You mix delete and trash here. In order to trash a new file you need to make room, for instance by emptying the trash -- no real contradiction there. And if you have no free disk space, then simply trashing files wouldn't give you -any- more disk space, even if trashed files didn't take more space.... So if you're out of disk space you -do- need real deletions anyway, not just trashing files. I think this is a WONTFIX. What we might want to do instead is detect almost-full partitions and offer to empty the trash before the user gets into this situation, (and/or implement a max trash size that purges old trashed files).
> (but I'm ready to admit that this small downside of the chosen solution > wasn't really foreseen, maybe we should have used a single info file to at > least minimize the changes of this happening). Yes! :-) And empty trash would still have one trashfile info. > > in order to delete something she/he has to delete someting > You mix delete and trash here. Sorry for that -- in whole report: by "delete" I meant "move to trash". > In order to trash a new file you need to make room, for instance by emptying > the trash Trash was empty. > And if you have no free disk space, then simply trashing files wouldn't > give you -any- more disk space, even if trashed files didn't take more > space.... Trashing no, but emptying trash after -- yes. > So if you're out of disk space you -do- need real deletions anyway, not just > trashing files. Nope. Put yourself in the regular user position -- user knows about trashing files and emptying trashcan. So he/she wants to do that exactly to empty space, but as I described above, there is misdesign and actually trashing file requires MORE resources than before. > What we might want to do instead is detect almost-full partitions and offer > to empty the trash before the user gets into this situation, Once again -- trash is empty. > (and/or implement a max trash size that purges old trashed files). Good idea, but for this case it is not a solution -- trash is empty. The problem is not with the user, space, or anything, but trashing design. The one file per whole trash is correct design. Current one is this And one more thing from UI perspective -- trashcan system is a great analogy to real life. To make more room in your apartment you can put some stuff into a trashcan and then empty it, right? You do not throw things out of the window. So there is no point in forcing user to learn new, dangerous things (for regular user) where good design of well know pattern can solve the problem.
OK, you convinced me. I posted on the xdg freedesktop list and Joe Mason immediately mailed me with an excellent solution to the problem: "The easiest fix for this is to add some padding to the trash that can be replaced by the .trashinfo files if there's no other space left." This seems like a nice solution indeed. I might get around implementing it at some point, when my TODO list has less urgent items in it :-)
I like much better your solution ;-) -- one persistent .trashcan info file (ok, it may be resized in advance).
No "my solution" is out of the question. It would mean changing the spec and making things incompatible again, just for a corner case. I prefer the "making a padding file" solution because it is an implementation detail, which doesn't require a spec change that would break all current implementations.
Is this still an issue with KDE Frameworks 5.45 or greater?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!