When moving dozens of files to trash, and while having lots of files already sitting in the .Trash directories, gvfsd-trash uses 100% of CPU, and Thunar also uses a lot of CPU for minutes while being unresponsive. I first thought this was a bug with gvfsd, which I have filed a report there: https://gitlab.gnome.org/GNOME/gvfs/issues/416. It turns out it may just be the way Thunar generates a lot of requests to gvfsd. Please see the linked issue for more details. Apparently Thunar would need the same fix as Nautilus to avoid generating requests to gvfsd-trash within a short amount of time ( https://github.com/xfce-mirror/thunar/blob/master/thunar/thunar-trash-action.c )
Thanks for reporting ! I will have a look into it when I have time.
Encountered same issue.
About which numbers we are talking here ? I just moved 2000 files into trash to "prefill" it, and than added another 100. The first 2000 took a small while. But the 100 afterwards went real quick for me. Edit: Uh, wait, I just tried to trash another 100 when tree-view is open: Seems like we have a tree-view bug here.
Can you reproduce the bug as well on bookmark view ? For me it only happens on tree-view.
Seems to happen both with shortcuts and tree view for me.
My stats: I had about 12000 items in trash (about 1GB). Adding another 3000 items (60MB in total) produced this behaviour. Treeview in the left sidebar is enabled. Main view is "detailed list".
I just tried to empty my trash ( 15000 item; about 1GB) and it raised the CPU to 100% on i5 quad(?) core. I canceled the process after about 1.5 minutes. Thunar also start to hang. Maybe as a hint: using trash-empty ( package: trash-cli ) did the job in a very smooth and fast way.
On Arch Linux I use "gio trash --empty" which is very fast, unless Thunar is running, in which case it will hang and use a lot of CPU as it's probably monitoring the trash directories. So using that or using Thunar's empty trash shortcut gives the same problem.
Created attachment 9014 WIP patch (In reply to fuank from comment #8) > On Arch Linux I use "gio trash --empty" which is very fast, unless Thunar is > running, in which case it will hang and use a lot of CPU as it's probably > monitoring the trash directories. So using that or using Thunar's empty > trash shortcut gives the same problem. That was an excellent hint, thanks ! I tried to diable different thunar file monitors, and found out that the "bookmark_monitor" makes a big difference for me when executing "gio trash --empty". I am not sure why two different files create a "bookmark monitor" ... possibly that is the problem. Before checking details, could you please try if the attached patch fixes the bug for you ? (No bookmark monitor at all)
Thanks alexxcons. I have tested again (without your patch) in 1.8.9 (release) and you are right, this only occurs with tree view active. However, even with your patch applied (with latest commit 47b32e784823a706f47a3188b258b803160c2426), the issue still happens with tree view.
Take a try for the patch on this bug: https://bugzilla.xfce.org/show_bug.cgi?id=16641 .. very promising
Uh, wait, not related .. this bug is about moving to trash, the other one is about permanent deletion
.. just found a duplicate of this bug, which isolder .. so I will close this one *** This bug has been marked as a duplicate of bug 12635 ***
Sorry, I was to fast with closing it a a dup. Bug #12635 seems to be not related to tree-view
The solution is to simply rate limit requests made to gvfs-trashd whenever a change occurs in the trash directory, as they did in Nautilus here: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/57/diffs So a fix would most likely be implemented in that file: https://github.com/xfce-mirror/thunar/blob/master/thunar/thunar-trash-action.c
My comment was perhaps a bit hasty. After looking closer it might not be as straightforward as I made it sound. I'm not sure why the callback thunar_trash_action_changed() seems to be called twice for every change of the trash state. Might be due to thunar_file_watch(trash_action->trash_bin) (https://github.com/xfce-mirror/thunar/blob/c5b2663c8fca74f9e191c56bc39e969f82752801/thunar/thunar-file.c#L3981) which triggers the second call or something. I've tried hacking around a bit but things are beyond my understanding right now.
You might want to take a try for this branch: https://github.com/alexxcons/thunar/tree/ReplaceGtkAction45 There is no thunar_trash_action any more, GtkActions got completely replaced .. can you still reproduce ? ... hopefully I will be able to merged that branch into master soon .. working on that currently
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/259. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev