With Thunar 1.5.2 from PPA, if you put a file in the trash, then trash is not empty and you can empty the trash. But if you close the session et open it then thunar shows an empty trash and you can't empty it
Fixed in 60e9680.
Still an issue here with 1.6.0. Closing all thunar windows and then opening a new one corrects the trash state. Alternatively calling 'gvfs-ls trash:' before opening thunar the first time also sets the correct trash state.
Still have this problem too with thuanr 1.6.0
Its a race, but the gvfs-trash daemon does not send a file-changed signal. With the idle it looked like it was fixed, but i can delay it too.
Delayed check to 2 seconds. Can someone check if this works?
Isn't working neither with xfdesktop nor with Thunar (1.6.1).
Code is checking for 15 seconds now with 3s intervals or files are found.
Sorry, but this is still not working with Thunar 1.6.2 But maybe this patch is not include in it
*** Bug 10655 has been marked as a duplicate of this bug. ***
I cannot reproduce this issue anymore after telling xfdesktop(!) to display the trash icon on the desktop.
Is this still an issue? If it is, please reopen.
(In reply to Harald Judt from comment #11) > Is this still an issue? If it is, please reopen. Yes, it is. Thunar build from git (afe91e9). As Thaddaeus Tintenfisch said in #10, it works fine, *if* xfdesktop is configured to show the trash icon on the desktop. For all desktop configurations not enabling the desktop trash icon, thunar shows always an empty trash on startup after a fresh login. So do all further thunar instances started later. To get the correct status, one must delete a file/folder or close all open thunar windows. The next thunar window will then show the correct status. Btw. my workaround for this issue is to create a autostart entry calling "gvfs-ls trash > /dev/null". So my guess is, that calling "gvfs-ls trash" initializes something thunar is relying on to determine the trash status.
I've been looking into this a bit. As some have observed, it happens when the gvfsd-trash daemon has not spawned and thunar accesses the trash for the first time (yet causing it to spawn). So for the trash bin having the correct state it is necessary that the daemon has already spawned when reading the info. The gvfs-trash ls command or any other application accessing the gvfs trash does this. To reproduce this more easily, simply kill thunar and gvfsd-trash and start a new instance of thunar (daemon or window shouldn't matter). The code added to thunar-session-client.c could work, but it never gets called on my machine, presumably because I do not start thunar with the session manager. If that is true, all people with a similar setup will suffer from this too. Also the thunar trash panel plugin could exhibit the same problem.
Created attachment 6251 fix-loading-the-trash-bin-status-at-startup-bug-9513.patch Attached is a patch which fixes the issue for me. Please try it and report back if it fixes the issue for _you_ too. At the moment, I cannot think of a better solution. I hope it does not produce crashes. Maybe someone else has a better idea and can comment on this. The first reload (in idle without timeout) fixes the shortcut/treeview status icon, but it needs at least a second reload (after two seconds) to fix the "go to" menu item entry. That symbol always shows "full" initially (though strangely thunar_file_get_item_count tells 0). The third reload is there just to be safe. Reloading the trash shouldn't be a very expensive operation. Please check the behaviour with and without this patch.
Created attachment 6252 fix-loading-the-trash-bin-status-at-startup-bug-9513.patch This is probably a better version of the patch. Instead of putting the checks into thunar_file_get, which could be called quite often for folders that contain a lot of files, put it into the main function which gets called only once per thunar instance.
(In reply to Harald Judt from comment #15) > Created attachment 6252 > fix-loading-the-trash-bin-status-at-startup-bug-9513.patch > > This is probably a better version of the patch. Instead of putting the > checks into thunar_file_get, which could be called quite often for folders > that contain a lot of files, put it into the main function which gets called > only once per thunar instance. Applied the second version of the patch and it fixes the issue for me. No side effects so far.
Pushed to master: http://git.xfce.org/xfce/thunar/commit/?id=2d5567b2f6ae6223c8865547704797a5c785ec1f Reverted changes to session client: http://git.xfce.org/xfce/thunar/commit/?id=61e52c7d53bf612b532dd1b8d7d49352cee1597e Fixed icon in path entry not updated: http://git.xfce.org/xfce/thunar/commit/?id=6c4676ad0197287bea2e033766443d35fb8be22e
The patch that I pushed to master and is included in thunar-1.6.9 has caused issues for other people (see bug #11913). I have pushed further patches to fix this, which should be included in the next bugfix release thunar-1.6.10. Could you please apply try these patches on thunar-1.6.9 in this order to see if you can find any issues? Revert patch: http://git.xfce.org/xfce/thunar/commit/?id=e3b65ff628499248dadfe7cbdb027e17b7db03c2 Fix reload return type: http://git.xfce.org/xfce/thunar/commit/?id=9bf051a0005cef3d661493a44e7de911868cf5e7 Fix trash status: http://git.xfce.org/xfce/thunar/commit/?id=6010f71d865b624f5f58b81405764c4ce6b2afc4 Alternatively, you can build thunar-git of course.
Build thunar from current master (6010f71). Trash status works fine and I haven't found any regressions so far. Admittedly I've looked primarily at the 'empty trash after first start'-issue.
Thanks for your report and test, so I will close this bug again.