Trashing many files causes Thunar to hang

Alexander Schwinn @alexxcons said:

Thanks for reporting ! I will have a look into it when I have time.

DarkTrick said:

Encountered same issue.

Alexander Schwinn @alexxcons said:

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.

Alexander Schwinn @alexxcons said:

Can you reproduce the bug as well on bookmark view ? For me it only happens on tree-view.

fuank said:

Seems to happen both with shortcuts and tree view for me.

DarkTrick said:

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".

DarkTrick said:

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.

fuank said:

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.

Alexander Schwinn @alexxcons submitted a 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)

Patch 9014, "WIP patch":
0001-Deleting-many-files-causes-Thunar-to-hang-Bug-15871.patch

fuank said:

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 47b32e78), the issue still happens with tree view.

Alexander Schwinn @alexxcons said:

Take a try for the patch on this bug: https://bugzilla.xfce.org/show_bug.cgi?id=16641 .. very promising

Alexander Schwinn @alexxcons said:

Uh, wait, not related .. this bug is about moving to trash, the other one is about permanent deletion

Alexander Schwinn @alexxcons said:

.. 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 ***

Alexander Schwinn @alexxcons said:

Sorry, I was to fast with closing it a a dup. Bug #12635 seems to be not related to tree-view

fuank said:

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

fuank said:

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.

Alexander Schwinn @alexxcons said:

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

Just tried it with master: still happens.

Note: Restoring the files is also extremely slow. About 5 sec per file (i.e. 3.5hours for restoring 2600 files). But that also happens here with only 5 to 10 files. Maybe a VM problem?

While building a testenvironment I figured thunar also takes *a lot of time for moving and renaming many files. Regarding moving with about 2600 files a 400kb:

mv file* ./target took about 1 second(?) (I couldn't even start counting. It finished right after pressing enter)
Thunar: about 16 seconds ("detailed" view)

Why am I saying this? Because there might be a general problem with the moving process (I guess trashing is also just a "move to trash"-move operation (?)

Thunar: about 16 seconds ("detailed" view)

Regarding "move" in general: To be checked if that's only a thunar problem, or if the slowness comes from g_file_move .. same for nautilus/nemo, which probably as well rely on g_file_move .. is it faster there ?

Further diagnostic would be very welcome !

Summary:

Nautilus does not hang, while Thunar does hang.
Apparently there is also a problem with g_file_trash, that makes gvfsd-trash go crazy.

Testdata

2600 files, each 400kb
total size: roughly 1gb

Test with Thunar (master)

Time needed: 23 sec
Deletes files: yes
Hanging: yes, during and after the operation
gvfsd-trash: 100% while running and after run finished
tracker-miner-f:

Test with Nautilus

Time needed: 30 sec
Deletes files: yes
Hanging: no
gvfsd-trash: 100% CPU while removing; 100% CPU after removing
tracker-miner-f: 70%

Test with dedicated program

Time needed: 15 sec
Deletes files: yes
Hanging: no
gvfsd-trash: 100% while running and after run finished
tracker-miner-f:

Source code:

Basically the code below gets called in a loop for each file.

  file = g_file_new_for_path (path);
  g_file_trash (file, NULL, &err); 
  if (NULL != err){ g_print("error: %s\n", err->message);
  g_object_unref (file);

Test with Thunar - changed thunar_application_trash

I changed the code to make deletions run in linear (no creation of the copy window) (Code changes below).

Time needed:
Deletes files: (probably yes)
Hanging: yes, during and after the operation finished.
gvfsd-trash:
tracker-miner-f:

I overrode the method thunar_application_trash() as follows.

void
thunar_application_trash (ThunarApplication *application,
                          gpointer           parent,
                          GList             *file_list)
{
  GError               *err = NULL;
  GList                *lp;

  _thunar_return_if_fail (parent == NULL || GDK_IS_SCREEN (parent) || GTK_IS_WIDGET (parent));
  _thunar_return_if_fail (THUNAR_IS_APPLICATION (application));
  _thunar_return_if_fail (file_list != NULL);

  g_print("start delete operation---\n");
  for (lp = file_list; err == NULL && lp != NULL; lp = lp->next)
    {
      g_file_trash (lp->data, NULL, &err);

      if (err != NULL)
        {
          g_print ("error deleting\n");
        }
    }
    g_print("finished delete operation---\n");
  //thunar_application_launch (application, parent, "user-trash-full",
  //                           _("Moving files into the trash..."), trash_stub,
  //                           file_list, NULL, TRUE, FALSE, NULL);
}

Thanks for the details !

I changed the code to make deletions run in linear (no creation of the copy window) (Code changes below). ...

Hanging: yes

So I guess more investigation is needed.

My assumption why your modified thunar_application_trash as well hangs is, that it is done in the main-thread, which is blocked for the time it takes. In any case, you should execute that code in a separate thread (ThunarJob/ExoJob). Currently code is already executed in a separate thread, so that is already fine, check _thunar_io_jobs_trash, which in the end is called via trash_stub ... possibly that extra-thread either blocks some resources of the main-thread or possibly updates on the trash-folder are triggered.

I would suggest to simplify _thunar_io_jobs_trash to see if that helps, and to check which part of the code actually causes the hang.

My assumption why your modified thunar_application_trash as well hangs is, that it is done in the main-thread, which is blocked for the time it takes.

Sorry, "Hanging: yes" was was unclear! Of course it "hangs" while in operation. I meant: after the operation (meaning after g_print("finished delete operation---\n");) Thunar still hang.

All in all, probably it would make sense to dig more into the direction the reported suggests (rate limit for file/folder updates). FOr that, best read the linked issue and the related merge request for nautilus.

We dont have s specific trash-monitor in thunar, but we have different file and folder monitors. Best search for g_file_monitor in the thunar codebase and put some printf into the related callback to see if one of them is called with high rate when trashing files.

mentioned in issue #391 (closed)

added 1. Performance 5. Trash / Delete labels

mentioned in merge request !369 (merged)

The following commit stops the freeze and makes trashing (10.000 files) fast again: alexxcons/thunar@3a49ea85

Though it comments out some code / removes some other services ... working on it.

mentioned in merge request !372 (closed)

Fixed by !429 (merged) by coincidence --> closing

closed

changed milestone to %4.19.3

mentioned in issue #1459 (closed)

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

marked this issue as related to #1459 (closed)

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

marked this issue as related to #1474 (closed)

Trashing many files causes Thunar to hang

Submitted by fuank

Description

Designs

Child items 0

Activity