Trashing many items temporarily blocks Thunar

Version information

4.18.11 Manjaro

Steps to reproduce

1. On your desktop, for example, do the following: mkdir testdir; cd testdir; seq 1 10000|xargs -n 1 mkdir
2. open the newly created testdir folder with Thunar (I just double-clicked it from the desktop)
3. select all of its items (CTRL-a)
4. move the selected files to trash, e.g. by hitting the del key

Current behavior

The items are being moved to the trash one by one, which takes a while (you can watch that from a terminal by doing ls -1|wc -l within the testdir). In during that period, Thunar is blocked, i.e. no Thunar windows (which previously have been opened from the desktop) can be closed or new ones opened (at least from the desktop; explicitly launching a new instance of thunar, e.g. via terminal, does work, and that one behaves normally, even correctly shows 10,000 items in trash), even for a good while after no items are left in testdir. In that period of time, the trash bin's shape does not change to "non-empty" either (if it had been empty before). The responsiveness of the overall system as such does not seem to be affected, windows can be moved around, other applications are running and can be switched to back and forth, etc. Top is showing gvfsd-trash to be running at full speed. This is probably OK as such (isn't it?), but it should not hang the running Thunar instance.

Expected outcome

The items are being moved to the trash one by one, which takes a while. Ideally, no blocking of Thunar should occur. Maybe a progress bar/dialog should appear.

I wonder whether or not this might be related to #259 (closed). In any case, shouldn't there be a progress bar anyway?

Yep, it's a duplicate of #259 (closed) ... closing as such. Cannot reproduce the bug on master. Using Manjaro you should even be able to install 4.19.3 as AUR if you want to test.

In any case, shouldn't there be a progress bar anyway?

There is a progress bar ... however, if it works reliably is not the matter of this issue.

changed the description

marked this issue as a duplicate of #259 (closed)

closed

marked this issue as related to #259 (closed)

Yes, I did install Thunar-4.19.3git-8b7853bc. Things are a bit better, but still the behavior is... say unexpected.

When I create 10,000 empty folders in a source folder on the Desktop and then select them all (ctrl-a) and move them to trash (del), the progress dialog comes up, but it stays visibly at no progress (i.e. 0%, although no percentage is given) and just says "in queue". I can watch in Thunar the number of folders in my source folder counting down to 0 (at a rate of maybe a few per second on my system), and once the source folder is empty the progress bar disappears (didn't see whether or not it first quickly went up to 100%). I can see with Thunar that the previously empty trash now contains 10,000 items. Once this is reached, gvfsd-trash continues to run at full speed (basically top says ca. 120%, i.e. using more than one core). (no issues with disk access or memory usage visible, nor with overall cpu usage). The shape of the trashcan still does not change to "filled". Although the system is responsive as normal and I can open new windows in Thunar, doupble-cklicking an item on the desktop (trash or folder) does not open it in Thunar, i.e. there is still some blocking effect.

After more than one hour, gvfsd-trash is done, the trashcan changes shape to "filled" and the Thunar windows corresponding to "delayed" clicks on items on the desktop pop up.

Similar situation when emptying the trash with 10,000 directories inside. The progress bar this time is slowly creeping along though (after a while it accelerates a bit). Hitting the pause button (which changes shape to a run button) does not pause that process, by the way. After hitting cancel in the progress bar, it goes away, but gvfsd-trash is still running at full speed and clicking on items on the desktop again has no effect (yet, probably deferred). Again, after gvfsd-trash finishes after a good deal of minutes, the delayed windows resulting from clicks on desktop items during that period pop up. Same situation when actually emptying the trash can.

So unfortunately this issue is not really resolved, therefore I am reopening it.

When I create 10,000 empty folders in a source folder on the Desktop and then select them all (ctrl-a) and move them to trash (del),

Please dont mix xfdesktop testing with thunar testing. Do you tests either with thunar, or with xfdesktop, but not both at the same time, otherwise it is hard to tell which program is to blame.

The shape of the trashcan still does not change to "filled".

That's a different bug and does not belong here.

(no issues with disk access or memory usage visible, nor with overall cpu usage)

though the system is responsive as normal and I can open new windows in Thunar

That is what was fixed in 4.19.x, and what this issue is about. If the blocking is fixed, this issue can be closed --> closing

Although the system is responsive as normal and I can open new windows in Thunar, doupble-cklicking an item on the desktop (trash or folder) does not open it in Thunar, i.e. there is still some blocking effect.

I suppose that is rather a problem of xfdesktop, not of thunar.

After more than one hour, gvfsd-trash is done, the trashcan changes shape to "filled" and the Thunar windows corresponding to "delayed" clicks on items on the desktop pop up.

Not thunars fault that gvfs takes forever. Please report that bad performance against gvfs: https://gitlab.gnome.org/GNOME/gvfs (Probably as well the reason for trashcan symbol not updating and delayed clicks)

reopened

closed