Deleting files from desktop freezes machine for short period

[Jussi]

Notice that this is repeat of old bug report, which was closed without working fix (see #1294209).

Deleting files from the desktop directly causes machine to freeze for ~30 seconds, once file is deleted machine responds in a timely manner again.

I experience this randomly, about 75% of the times.

Old bug report claims it is fixed in version 4.11.5-0ubuntu1 of xfdesktop4, but I still experience this with 4.11.6-1ubuntu1.

From ~/.cache/upstart/dbus.log

** (process:1678): WARNING **: *** Unsupported operation detected on trash directory

** (process:1678): WARNING **: A trash files/ directory should only have files linked or unlinked (via moves or deletes). Some other operation has been detected on a file in the directory (eg: a file has been modified). Likely, the data reported by the trash backend will now be inconsistent.

** (process:1678): WARNING **: dir: /home/jussi/.local/share/Trash/files, file: New File.5, type: 1

[Elfy (elfy)]

The first time I delete anything from the desktop, the system freezes for approximately 30 seconds.

This warning is found in .cache/upstart/dbus.log

** (process:8845): WARNING **: *** Unsupported operation detected on trash directory

** (process:8845): WARNING **: dir: /home/hob/.local/share/Trash/files, file: xubuntu-default-settings_14.04.2.tar.gz, type: 1

** (process:8845): WARNING **: *** Unsupported operation detected on trash directory

** (process:8845): WARNING **: dir: /home/hob/.local/share/Trash/files, file: xubuntu-default-settings-14.04.2, type: 1

Subsequent deletions from desktop in the same session, create no warning and do not freeze the system

[Eric Koegel (eric-koegel)]

Created attachment 5401
Use GIO directly for delete/trash operations

xfdesktop uses Thunar's dbus for trash/delete so I'm not sure why that error pops up, however since the operation doesn't really need a popup window showing the operations progress I wrote a patch to use GIO's built-in functions directly. Let me know if this fixes the issue.

[Elfy (elfy)]

Used Thad Tintenfisch's PPA with the patch included - file deleted from desktop as expected, with no system freeze

thanks

[Eric Koegel (eric-koegel)]

Thanks for testing it, pushed to master in:
http://git.xfce.org/xfce/xfdesktop/commit/?id=d48b40f6623a758ff128f5b22b2bd3e581b5b2a3

[Eric Koegel (eric-koegel)]

Reopening since this commit was reverted in http://git.xfce.org/xfce/xfdesktop/commit/?id=c79f244f8f1f2d08892a54cbb820211abad3287d

[Elfy (elfy)]

Odder behaviour associated with this being seen in Xubuntu 14.10 now.

Same issue with freeze after desktop deletes - now I am also seeing that if I delete, wait for the freeze, moving to a new desktop hangs in addition.

[EricDHH (ericdhh)]

This is mint17 xfce and show the same problem. 30 seconds stopped desktop, everything clicked are buffered and come up after this period. Deleting files from the desktop gives this in dbus.log

** (process:3063): WARNING **: *** Unsupported operation detected on trash directory

** (process:3063): WARNING **: A trash files/ directory should only have files linked or unlinked (via moves or deletes). Some other operation has been detected on a file in the directory (eg: a file has been modified). Likely, the data reported by the trash backend will now be inconsistent.

** (process:3063): WARNING **: dir: /home/eric/.local/share/Trash/files, file: staged-evolution.jpg, type: 1

[Eric Koegel (eric-koegel)]

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

[Francesco-dem (francesco-dem)]

Hi, i have the same problem on archlinux x86_64 (64bit)

[upkpk (upkpk)]

Hello everyone, I'm unable to reproduce this on Debian testing/unstable x86.
It would be nice if you could attach your version numbers for xfdesktop4 and thunar (as it seems to be related)

xfdesktop4: 4.10.2-3
thunar: 1.6.3-2

@elfy @francesco_dem, can you still reproduce this bug?

[Xodetaetl (ovocean)]

I'm having the issue with xfdesktop4 v4.11.6-1, thunar 1.6.3-1 .

[Francesco-dem (francesco-dem)]

(In reply to Julien [nodiscc] from comment #8)
> Hello everyone, I'm unable to reproduce this on Debian testing/unstable x86.
> It would be nice if you could attach your version numbers for xfdesktop4 and
> thunar (as it seems to be related)
>
> xfdesktop4: 4.10.2-3
> thunar: 1.6.3-2
>
> @elfy @francesco_dem, can you still reproduce this bug?

Hi Julien, i have thunar 1.6.3 and xfdesktop : 4.10.3-2.

[Francesco-dem (francesco-dem)]

(In reply to francesco_dem from comment #10)
> (In reply to Julien [nodiscc] from comment #8)
> > Hello everyone, I'm unable to reproduce this on Debian testing/unstable x86.
> > It would be nice if you could attach your version numbers for xfdesktop4 and
> > thunar (as it seems to be related)
> >
> > xfdesktop4: 4.10.2-3
> > thunar: 1.6.3-2
> >
> > @elfy @francesco_dem, can you still reproduce this bug?
>
> Hi Julien, i have thunar 1.6.3-2 and xfdesktop : 4.10.3-2.

[Elfy (elfy)]

(In reply to Julien [nodiscc] from comment #8)
> Hello everyone, I'm unable to reproduce this on Debian testing/unstable x86.
> It would be nice if you could attach your version numbers for xfdesktop4 and
> thunar (as it seems to be related)
>
> xfdesktop4: 4.10.2-3
> thunar: 1.6.3-2
>
> @elfy @francesco_dem, can you still reproduce this bug?

Yep.

Running Xubuntu VV dev currently

xfdesktop4: Installed: 4.11.8-0ubuntu1

thunar: Installed: 1.6.3-2ubuntu1

[Steve Dodier-Lazaro (sidi)]

Is the freeze caused by the Thunar daemon needing time to spawn, or by something else?

I have a completely unrelated instance of calling D-Bus via Thunar causing the caller to freeze (Firefox when opening the current folder, according to Mozilla folks currently debugging their use of the FileManager1 D-Bus interface).

Could it be that we should fix an issue in Thunar instead, and that this would take care of the freeze? As I understand it, the progress dialog can be useful when deleting large files from the desktop.

Thanks.

[Eric Koegel (eric-koegel)]

Moght be, the ~30 seconds sounds like the default dbus timeout. Not sure why it started showing up, especially for the 4.10 branch.

[Elfy (elfy)]

This just popped up in mailbox - I'm now NOT seeing this issue

xfdesktop4 - 4.11.8-0ubuntu1
thunar - 1.6.5-0ubuntu1

I've also got new hardware here now. (not sure if that's of any importance but thought I'd mention anyway)

[Langer Alexey (langer-alexey)]

Up! The problem remains actual.
It seems this is not a D-Bus, because at the time of freezing the entire desktop becomes inactive (does not respond to a click of the mouse).
xfdesktop 4.11.8
Thunar 1.6.3 (Xfce 4.10)
OS Xubuntu 14.04 x64
Three variants of the log .cache/upstart/dbus.log (process:2540 - is "gvfsd-trash"):
1)
** (process:2540): WARNING **: *** Unsupported operation detected on trash directory
** (process:2540): WARNING **: dir: /home/admin1/.local/share/Trash/files, file: nwjs-v0.12.0-rc1-linux-x64, type: 1
** (process:2540): WARNING **: *** Unsupported operation detected on trash directory
** (process:2540): WARNING **: dir: /home/admin1/.local/share/Trash/files, file: nwjs-v0.12.0-rc1-linux-x64.tar.gz, type: 1
=========================================================
2)
** (process:2540): WARNING **: *** Unsupported operation detected on trash directory
** (process:2540): WARNING **: A trash files/ directory should only have files linked or unlinked (via moves or deletes). Some other operation has been detected on a file in the directory (eg: a file has been modified). Likely, the data reported by the trash backend will now be inconsistent.
** (process:2540): WARNING **: dir: /home/admin1/.local/share/Trash/files, file: ubuntu-mate-15.04-beta1-desktop-amd64.iso, type: 1
=========================================================
3)
** (process:2540): WARNING **: *** Unsupported operation detected on trash directory
** (process:2540): WARNING **: dir: /home/admin1/.local/share/Trash/files, file: sibhost.ru-2014-01-13.zip, type: 1

Successfully activated service 'org.freedesktop.thumbnails.Cache1'

** (process:2540): WARNING **: *** Unsupported operation detected on trash directory
** (process:2540): WARNING **: dir: /home/admin1/.local/share/Trash/files, file: nw, type: 1

(Thunar:4281): GLib-CRITICAL **: Source ID 48139 was not found when attempting to remove it
(Thunar:4281): GLib-CRITICAL **: Source ID 49096 was not found when attempting to remove it
==========================================================

[Eric Koegel (eric-koegel)]

So it looks like it was a bug in gvfs which explains why it just
started showing up on the 4.10 branch.
https://bugzilla.gnome.org/show_bug.cgi?id=737473
https://git.gnome.org/browse/gvfs/commit/?id=1f2d2952135a1304b0ed66da1d3d8f60f1e1c06e

So any version of gvfs >= 1.23.1 should be fixed.

[Jussi (jussi-lahtinen-gmail)]

Confirmed with:
xfdesktop version 4.11.8
gvfs 1.20.3-0ubuntu1

dbus.log has the same error messages as originally.

[Eric Koegel (eric-koegel)]

Closing bug report as it was a bug in gvfs.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

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

[Benitron (benlarcher-1)]

Hello, as said by Eric Koegel, it appears that any version of gvfs >= 1.23.1 should be fixed.

The bug is also mentionned here https://bugzilla.xfce.org/show_bug.cgi?id=10778

I am on gvfs 1.20.3 and did all the update on xubuntu 14.04.

Isn't xubuntu 14.04 supposed to have LTS support so to include a "higher" gvfs version if the current one installed is bugging ? Or are we supposed to do it ourself ?

So I hope I post at the right place to ask if gvfs >= 1.23.1 could be integrated to xubuntu 14.04.

It not always easy to see where to post a request ;)

Anyway, have a nice day and thanks for the job you do !

[Mati86dl (mati86dl)]

Hi Eric,

> Closing bug report as it was a bug in gvfs.

Not completely.. But beyond this discussion, I think I can offer a small improvement.. ;)

> https://github.com/xfce-mirror/xfdesktop/blob/09ce3eb7f79225366c445e5a6639b9b7d0f1ac4d/src/xfdesktop-file-utils.c#L866

These set the watch cursor, but call the dbus proxy so quickly that never display the cursor..

Then (though the name of the function is _async), is doing all the main thread, freezing the desktop all the time that takes the file operations..

If you add these code in the line marked above force to update the gui, and to respond to new events like clicks on the desktop

> while (g_main_context_pending (NULL))
> g_main_context_iteration (NULL, FALSE);

The ideal is do this within the dbus interface, but as this constructed now is impossible. :S

Please.. Test.

Regards,
Matias.