Bug 245482

KDE trash is not managed by digiKam, but by KDE4...

Gilles Caulier

This problem was resolved by:

1. Installing dolphin set trash can to unlimited and tell it to delete every 7 days..


2. I also ran kdirstats as root to ensure there were no ghost trash files out there eating up disk space...

Now I can delete the files within the Digikam filemanager..


Strange that this even occurred...

Not sure what was triggering the error considering the trash can was empty and trash directories were empty when it occurred.

Just to be more clear, install Dolphin, then

Dolphin > settings> configure Dolphin >trash.

Message from Dolphin: "The wastebin has reached its maximum size! ..."

Here is my metadata file which had an absurdly high value (my total space is 0.5 TB)

$ cat ~/tmp/Trash/metadata
[Cached]
Size=18446744073708693256

- that's 18.447 exabyte (EB) / 16.000 exbibyte (EiB)

After copying the 5 files, emptying trash and deleting them again in the same order, the metadata was correctly stored.

$ cat ~/tmp/Trash/metadata
[Cached]
Size=1710296

I think I was using Kubuntu Lucid when I lost the use of the wastebin. OK now.

Below is a file list from the trash copy (probably useless):
dave@K-Matrix:~/tmp/Trash$ ls -oaR
.:
total 20
drwxr-xr-x 4 dave 4096 2010-10-03 03:49 .
drwxr-xr-x 3 dave 4096 2010-11-26 18:28 ..
drwxr-xr-x 2 dave 4096 2010-10-03 03:49 files
drwxr-xr-x 2 dave 4096 2010-11-26 06:11 info
-rw------- 1 dave   35 2010-10-03 03:49 metadata

./files:
total 1688
drwxr-xr-x 2 dave    4096 2010-10-03 03:49 .
drwxr-xr-x 4 dave    4096 2010-10-03 03:49 ..
-rw-r--r-- 1 dave   16356 2010-10-03 02:50 daxxinet_eco5_clean_NR_BK.sql.gz
-rw-r--r-- 1 dave   14179 2010-10-03 01:45 daxxinet_eco5_sql_clean_NR.gz
-rw-r--r-- 1 dave  455014 2010-09-12 14:00 DSC_0018.JPG
-rw-r--r-- 1 dave 1079613 2010-10-03 01:59 eco5.sql
-rw-r--r-- 1 dave  145134 2010-10-03 03:07 eco5.sql.gz

./info:
total 28
drwxr-xr-x 2 dave 4096 2010-11-26 06:11 .
drwxr-xr-x 4 dave 4096 2010-10-03 03:49 ..
-rw------- 1 dave  134 2010-10-03 02:52 daxxinet_eco5_clean_NR_BK.sql.gz.trashinfo
-rw------- 1 dave  131 2010-10-03 02:02 daxxinet_eco5_sql_clean_NR.gz.trashinfo
-rw------- 1 dave   85 2010-09-12 17:15 DSC_0018.JPG.trashinfo
-rw------- 1 dave  113 2010-10-03 03:13 eco5.sql.gz.trashinfo
-rw------- 1 dave  110 2010-10-03 03:13 eco5.sql.trashinfo
dave@K-Matrix:~/tmp/Trash$

----------

dave@K-Matrix:~/tmp/Trash$ cat info/*
[Trash Info]
Path=/home/dave/Downloads/concrete5/DfB_DB_SQL_exports/daxxinet_eco5_clean_NR_BK.sql.gz
DeletionDate=2010-10-03T02:52:16
[Trash Info]
Path=/home/dave/Downloads/concrete5/DfB_DB_SQL_exports/daxxinet_eco5_sql_clean_NR.gz
DeletionDate=2010-10-03T02:02:37
[Trash Info]
Path=/home/dave/new%20eco/DSC_0018.JPG
DeletionDate=2010-09-12T17:15:27
[Trash Info]
Path=/home/dave/Downloads/concrete5/DfB_DB_SQL_exports/eco5.sql.gz
DeletionDate=2010-10-03T03:13:35
[Trash Info]
Path=/home/dave/Downloads/concrete5/DfB_DB_SQL_exports/eco5.sql
DeletionDate=2010-10-03T03:13:35
dave@K-Matrix:~/tmp/Trash$

----------

I just run into the exact same problem on ubuntu 10.10 with KDE 4.5.1 with the message "The trash has reached its maximum size! Cleanup the trash" when the trash bin is empty.

Running cat ~/.local/share/Trash/metadata gives

[Cached]
Size=18446744070697993799

My typically usage pattern of the Trash has been "Shift + DELETE" with the selected file in Dophin. So there shouldn't be any file in the trash bin. When the problem occurred, I verified the trash bin is indeed empty.

Removing the metadata file seems to fix the problem.

*** Bug 246030 has been marked as a duplicate of this bug. ***

*** Bug 270886 has been marked as a duplicate of this bug. ***

*** Bug 232992 has been marked as a duplicate of this bug. ***

Same as comment 5, except that I don't get a message — instead, every new item put in the trash bin replaces an old one.

Quick fix: deleting metadata or emptying the bin fixes the problem.

Reproduce: writing a bogus huge size in metadata is enough to cause it.

Notes: I've seen bogus huge numbers in metadata several times in the past after the trash-bin accumulates a lot of files (possibly also after root-owned files the user can't delete end up in the bin); I don't know if this is due to KDE (quite possibly) or other trash implementations (I've used trash-cli before). Since the specification (http://standards.freedesktop.org/trash-spec/trashspec-latest.html) doesn't even mention a metadata file, I assume it's KDE. Besides fixing whatever causes these wrong numbers, I suggest adding a sanity check of some sort to the size.

Comment to anyone unable to "empty the bin" properly: delete the whole of ~/.local/share/Trash (via sudo if necessary).

I just had the problem that I could not remove files from Amarok. Removing
    ~/.local/share/Trash/metadata
solved it for me.

Regarding #10: If you need sudo to remove that, there is something wrong. Rather check file permissions then going there with an axe.

I just had a quick look at the code and though, maybe

diff --git a/kioslave/trash/trashsizecache.cpp b/kioslave/trash/trashsizecache.cpp
index 2fae964..f5c6e7b 100644
--- a/kioslave/trash/trashsizecache.cpp
+++ b/kioslave/trash/trashsizecache.cpp
@@ -71,7 +71,11 @@ void TrashSizeCache::remove( qulonglong value )
     KConfigGroup group = config.group( mTrashSizeGroup );
 
     qulonglong size = currentSize( false );
-    size -= value;
+    if ( value >= size ) {
+        size = 0;
+    } else {
+        size -= value;
+    }
 
     group.writeEntry( mTrashSizeKey, size );
     config.sync();

at least after the short look makes sense and the lack of any test here might cause the problem.

It's an unsigned long long, which is 64 bit ... whis is the number that is set as size ...and then everything blows up. So I guess value is in certain cases bigger than size.

If these certain cases should be investigated if beyond me though.

Re 11: yes, it's drastic. But Trash is trash and the spec says if the directory doesn't exist it should be created, so I don't see a real problem. Making sure all files are user-modifiable and deleting metadata should solve all issues though, yes.

Re 12: great! I suppose updating metadata and adding/deleting files atomically is impossible (i.e. crashes at the wrong moment, someone else simultaneously editing metadata, or whatever, could cause problems). That should help.

What should be even more robust would be to list the size of each trash item in metadata separately, and auto-generating any missing items. (Shouldn't be more than a few thousand items in the trash at most, so reading & summing the list should be fast. And items in the trash aren't likely to be modified, so it ought to be reasonably robust.)

Just my two cents!

I've ran into this problem too, and found the bug on google while looking for a solution. openSUSE 12.2, KDE 4.8.5. The trash is limited to 10% of my root partition space which means 17GB. While the trash was empty, I was unable to delete any files including empty 0-byte ones. The message was that the trash reached its limit and I should empty it. It would only work when disabling trash limit from Dolphin settings.

I followed the workaround posted here, and deleted the /home/(username)/.local/share/Trash/metadata file. This indeed solved the problem. I looked inside that file before and after, and saw the following:

[Cached]
Size=(number)

(number) was very big when the issue was happening. Once the metadata file was re-created (once I deleted a small test file) it became much smaller. This leads me to think some issue is causing it to get set to a high value, or the trash doesn't notice when removing some files from it and forgets to decrease that value.

*** Bug 293573 has been marked as a duplicate of this bug. ***

*** Bug 300278 has been marked as a duplicate of this bug. ***

I can confirm that this bug always and consistently occurs when removing large files from USB media (e.g 7 GB file from a 16GB stick), and it has occurred for every KDE 4.x version I have ever used up until at least 4.9. 

There is no graphical way of actually removing the file.

My solution is to use "rm" within the inline command line to actually delete the file. This is however no solution for novice users.

The solution to this problem would be to offer a solution in the dialog to permanently delete the file.

can comfirm this is happening with Xubuntu 12.10 still.
After upgrading from Ubuntu 12.04, reinstalling all applications but keeping the profiles (.xyz in $HOME) digikam kept reporting "trash folder full...."  .
RM'ing the bespoke "metadata" file solved the issue for now.

When afterwards deleting a single picture ( ~1.5 MB) the number went straight up to :
[Cached]
Size=900410516

which is about the correct size of all files in Trash at that time.

this is an annoying bug.. the problem to me is that if you connect a usb stick, dolphin has a defauklt to automatically set its trash size to 10% of the USB stick space. So, if you trash for ex. a 700mb video from a 4gb stick, you are prompted by "Cannot delete file, reached max space limit" alert, which levaes the user in total despair.
I couldn't figure wat was the problem to free some space, I couldn't imagine a less trained user's pain..

So i propose to:
1 - don't use trash size limit by default, even on the hd
2 - improve alert text, adding a way to deal wih the problem (better description / shortcut button)

(In reply to comment #17)
> My solution is to use "rm" within the inline command line to actually delete
> the file. This is however no solution for novice users.
> 
> The solution to this problem would be to offer a solution in the dialog to
> permanently delete the file.

This is possible, but it needs to be explicitly enabled: open Dolphin (or Konqueror), click Control → configure Dolphin → Services, and enable delete. Also in General → Confirmations you can control delete/trash confirmations.

so 4.10 is out and this usability bug has faced the very first time i tried to delete a movie from a 16gb pendrive.
anyone stepping out to fix this thing once for all?
maybe contacting kde-usability mailist?
maybe adding a blocker to extra-mile?

KDE people, please, think about the hapless users who don't think it is a lot of fun to Google error messages.  Please learn to do two things:  write helpful error messages and make things user friendly.

In the reverse order:

It is very ill-conceived to have the first use of "delete" respond with "the trash has reached its maximum size"

It is plain stupid negligence to have that message mean you must:
   rm ~/.local/share/Trash/metadata

I am sorry to sound like a crank.  Maybe I am one.  But spending a half hour chasing down problems because the trash is full on first use?  I think that deserves some crankiness.  Sorry.

Bug still happens in KDE 4.10.2

*** Bug 320413 has been marked as a duplicate of this bug. ***

so, 4.11 will be THE LTS release and users will encounter this bug dated 2010 for years to come.

does anyone care if a user won't be able to simply delete, for ex, a 700mb file from a 4gb usb stick because of the _default_ 10% trash size limit and because, being the error message wrong ("delete manually trash folder"), s/he doesn't know a workaround?

there are easy, easy, solutions out there:
1. STOP defaulting to 10% trash limit to every partition.
2. in error msg, point to the right place for modifying settings with a shortcut button
3. is there a real need for a trash size limit? trash can isn't that hidden mystic place where no one never goes..

please, fix it before Release Candidate comes out, please.. KDE for  e v e r y o n e !

So there are two bugs here, as far as I understand it:

1) The total size of files in the trash is cached (I think so that if directories containing many files are trashed, recalculating the size is fast), and the cached value is quite often absurdly wrong.
There was some progress on this (on the mailing list) including a proposed revision to the freedesktop trash spec. Don't know how far this got (I stopped watching the list).

2) The behaviour when "trash doesn't contain enough space" is not very good. Improvements could be made here:
a) check the cached size is correct (especially if it's absurdly big)
b) offer to immediately delete the file, especially if it's too big for the trash bin anyway
c) suggest emptying trash, perhaps with a button to open in Dolphin
d) suggest changing auto-empty policy, with link to settings

I'm not sure I agree with removing the default 10% limit as Joseph suggests.

So, to make progress, it needs someone to commit some code. If you don't want to get neck deep in this I'd suggest only try to fix (2) (since someone's already started (1)). Anyone willing to give this a go?

Changing the 10% limit may be debatable (its debatability is debatable -- due to Joseph's point 3), but what is _COMPLETELY_ _NOT_ debatable is the overriding necessity of addressing his point #2:  For God's sake, make error messages actionable so folks don't have to go through Google/filter the hits/Google cycles until they stumble across what they should have been led to from the error message.  To that end, "Trash has reached maximum size please clean manually" (when the trash is already empty) is completely useless.

about trash size limit.

i think that, better than putting a limit (quantified in percentage too) to trash size, causing issues in many real life cases (for ex. i want to trash my 700mb file exceeding the 10% limit, but i don't want to erase it still), the "no space available" situation should be taken care by the free space notifier daemon. If there is no space available it gives the user advice how to free some, or it should offer a shortcut button to launch sweeper app if installed.

Maybe trash size limit is something dating back when disk space was not cheap.
and, again, every user has the notion of "trash can" in computing. 
After all, why someone should bother at all about trash size if there is still free space available?

I can confirm the bug. I deleted the trash folder do circumvent this bug. Emptying the Trashcan didn't work.

I confirm this on Ubuntu 12.04 64 bit, deleting thsi file:
rm ~/.local/share/Trash/metadata

resolves the situation

Created attachment 84380 [details]
Screen capture of 40+ month old bug on Kubuntu 13.10

Not very impressive people. I have always heard that problems with this open source OS are handled quickly. And, yet, it's now been over THREE YEARS since this bug report was initiated and I am having the exact, same, problem with at least two different flash drives on Kubuntu 13.10. . . 

When will this bug be resolved?
Is anybody working to solve this?
I am seeing bugs that are well over a year old including a couple others I am dealing with here and, at this point, wondering IF, not when, these bugs will ever be fixed?
Sorry to say but this is similar to how windows releases a new OS that still has the same, known, bugs that were in the previous versions. . . . 

Please respond.
Kindest regards;
Scorch.

Ok; so I tried finding the file: "rm ~/.local/share/Trash/metadata" by searching in dolphin.
No such file found which brings us to another bug: Dolphin "options" are disabled or, otherwise, greyed out and search not finding files known to be on the system. . . 
See bug: 328086

Can you, please, provide the entire directory tree so I might find it manually?

Please respond.
Kindest regards;
Scorch.

Scorch, I can't tell you when this bug will be resolved, though someone was doing some work on it at some point.

Work-around using dolphin:

1) In Dolphin: Control → Configure Dolphin → Services → check the "Delete" option. This will allow you to directly delete files instead of moving them to trash (both options show in the context menu).
2) In Dolphin again, press Ctrl+L or click in the location bar so that you can type there
3) Paste and go to ~/.local/share/Trash
4) Right click on the "metadata" file and click delete

*** Bug 329103 has been marked as a duplicate of this bug. ***

Enabling the "Delete" service helped me to get rid of my problem deleting a 9gb folder on a 16gb usb stick. In this situation you simply cant move things to Recycle bin. 9gb*2=?
Dont do anything fancy, I dont want to google to delete a file. Just ask if files should be deleted permanently and done.

The bug i.e. wrong "metadata" file can still occur as recent as Linux Mint 16 / Ubuntu 13.10 / KDE 4.11.

However KDE 4.13 doesn't check whether metadata contains valid value.

The question is, what caused "metadata" file to have such a large number, even though the trash is empty?

Confirmed on Ubuntu 14.04, digiKam 3.5.0, KDE 4.13.2, running Unity.

Previously I used to copy files over from my NAS box (mounted over by NFS) to local hd and edit them there, but now I started editing images in digiKam directly over NFS - and this started happening. Something related to deleting (and thus creating a .Trash-1000) in the network share instead of local file delete?

Deleting ~/.local/share/Trash/metadata solved this temporarely.

Another solution which works well for me is to turn off the size limit: Dolphin → Control → Configure Dolphin → Trash → uncheck "Limit to maximum size"

This required an update to the trash spec, which has been done at the last freedesktop summit (see trash spec v1.0).

The new solution doesn't require cooperation from all apps, the cache can recover from apps not updating the cache. I implemented it in July, commit 591acfe8f5e281f416ee925e1ff160c0aac81163 in kde-runtime, branch Applications/14.12.

*** Bug 342294 has been marked as a duplicate of this bug. ***