Deleting files from desktop freezes machine for short period

Bug #1294209 reported by Elfy on 2014-03-18
64
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Xfce4 Desktop
Fix Released
Medium
xfdesktop4 (Ubuntu)
Undecided
Jackson Doak

Bug Description

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

Noticed this behaviour over the last few days.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: thunar 1.6.3-1ubuntu4
ProcVersionSignature: Ubuntu 3.13.0-18.38-generic 3.13.6
Uname: Linux 3.13.0-18-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue Mar 18 16:23:40 2014
SourcePackage: thunar
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Elfy (elfy) wrote :
Elfy (elfy) on 2014-03-20
summary: - Deleting files from desktop freezes machine
+ Deleting files from desktop freezes machine for short period
Elfy (elfy) on 2014-03-21
affects: thunar (Ubuntu) → xfdesktop4 (Ubuntu)
Jackson Doak (noskcaj) wrote :

This would probably be caused by the 4.11.4-1ubuntu1 release, of which the upstream changelog is:
4.11.4
======
[Please note that this is a development release.]

Fifth development release of xfdesktop targeting for Xfce 4.12.
Please report all problems at bugzilla.xfce.org.

* Versioned help:
  - Point to the docs.xfce.org page for xfdesktop 4.11. (Bug 10736)

* Build errors with some compiler flags:
  - dbus-glib is now required. Since xfconf requires it and
    xfconf is already required for xfdesktop, this shouldn't
    change dependancies much for xfdesktop. This bug was reported
    and fixed by Samuli Suominen. (Bug 10745)
  - Another build failure when disabling the menu and requiring
    exo was also resolved.

* Icon changes in the settings app:
  - Symbolic icons have issues with some gtk2 themes where they
    don't get colored properly. Additionally some themes don't
    have network-fs or gnome-dev-network so it has been changed
    gtk-network.

* Right click edits launchers:
  - When performing a right click, or shift + left click, on an item
    in the applications sub-menu of the desktop menu it will now pop
    up the dialog to edit the launcher. Same as xfce4-appfinder.

* Better migration from previous versions:
  - Xfdesktop now does a better job of migrating any user settings
    from 4.10 and before to the new xfconf properties.
  - Fix an settings issue when plug names aren't available

* Clean up some user strings:
  - Some tooltips end with a period, some do not. This has been
    unified.
  - "You are using more than one display, move this dialog to the
    display you want to edit the settings for." This takes a lot of
    space and brings along a bit of redundancy. Changed to "Move this
    dialog to the display you want to edit the settings for."
  - "Other items" on the third tab, below removable devices: "devices"
    replaces "items".
    Thanks to Harald Judt for pointing these issues out.

* Remember the window size of the settings dialog
  - Patch written by Harald Judt.

* Fix segfault on session start
  - Patch written by Thaddäus Tintenfisch

* Miscellaneous bug fixes:
  - Iconview theme/gtkrc color/style issues resolved.
  - Issues with folder cover art not loading have been fixed.
  - Make xfdesktop-settings pluggable again (Bug 10714)
  - Update the wallpapers after user sets folder in the settings
    app.
  - Minimize grid resizes, it now won't recalculate icon positions
    if the grid size didn't actually change.
  - Memory leaks fixed.
  - Warnings that happened during runtime have been fixed.
  - Fix a crash when removing displays
  - Show add/remove workspace option is on by default

* Translation updates: Bulgarian (bg), Chinese (Taiwan) (zh_TW),
  Croatian (hr), Danish (da), German (de), English (Australia) (en_AU),
  French (fr), Italian (it), Japanese (ja), Korean (ko), Malay (ms),
  Russian (ru), Serbian (sr), Spanish (Castilian) (es), Thai (th)

Elfy (elfy) wrote :

Updated machine - still seeing this behaviour here.

Pasi Lallinaho (knome) wrote :

FWIW, can't reproduce on a newly installed 64-bit Xubuntu with today's image. Does this happen with all kind of file types and sizes?

Elfy (elfy) wrote :

Anything that you might want to delete.

Pasi Lallinaho (knome) on 2014-03-28
Changed in xfdesktop4 (Ubuntu):
status: New → Incomplete
Elfy (elfy) wrote :

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

Got this in .cache/upstart/dbus.log

In , Elfy (elfy) wrote :

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

Arch bug report filed against gvfs: https://bugs.archlinux.org/task/38853

Changed in xfdesktop4 (Ubuntu):
status: Incomplete → New
Changed in xfdesktop:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

In , Elfy (elfy) wrote :

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

thanks

Changed in xfdesktop:
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xfdesktop4 - 4.11.5-0ubuntu1

---------------
xfdesktop4 (4.11.5-0ubuntu1) trusty; urgency=medium

  * New upstream release. LP: #1294209
  * Drop patches taken from git, fixed upstream.
 -- Jackson Doak <email address hidden> Wed, 02 Apr 2014 06:58:37 +1100

Changed in xfdesktop4 (Ubuntu):
status: New → Fix Released
Pasi Lallinaho (knome) on 2014-04-14
Changed in xfdesktop4 (Ubuntu):
assignee: nobody → Jackson Doak (noskcaj)
Jussi (jussi-lahtinen-gmail) wrote :

As usually bug report is closed too soon.
I experience this bug on Xubuntu 14.04, xfdesktop4 4.11.6-1ubuntu1.

Jussi (jussi-lahtinen-gmail) wrote :

This bug has been re-reported, because the fix doesn't work:
https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1319029

Changed in xfdesktop:
status: Fix Released → Confirmed
In , Elfy (elfy) wrote :

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.

Wormhole (fabio-iannone) wrote :

Same Problem

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

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

Jon Forsberg (jon-orebro) wrote :

Deleting things from the desktop doesn't cause the system to freeze for me but is still very slow. Deleting two empty directories takes 2-3 seconds...
xubuntu 14.04
xfdesktop4 4.11.6-1ubuntu1

fv (fratiman-vladut) wrote :

Same problem.
If trash is empty, then when i delete any file, hdd is busy for about 30s (in my case).
After that , when delete another file, everything work fast.

xubuntu 14.04
xfdesktop4 4.11.6-1ubuntu1

In , upkpk (upkpk) wrote :

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?

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

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

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

In , Elfy (elfy) wrote :

(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

Changed in xfdesktop:
status: Confirmed → Incomplete

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.

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

In , Elfy (elfy) wrote :

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)

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
==========================================================

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.

Closing bug report as it was a bug in gvfs.

Changed in xfdesktop:
status: Incomplete → Fix Released

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

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.