Thunar 1.6.3 locks when browsing Trash with Xubuntu 13.10 Beta 2 and following dailies

Bug #1231978 reported by David on 2013-09-27
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Fix Released
gvfs (Ubuntu)

Bug Description

Clean install of 13.10 beta2 64bit Xubuntu

New user home folder created at install.

Previous home folder was renamed to david-old before install of 13.10

Deleting files from this old home folder from previous install and copying files I want to keep to the new home folder.

Click on trash can either desktop or via Thunar side bar and Thunar manager locks. Eventually force close window pops up.

Related branches

David (david-9ei9nyjpwdex) wrote :

Fault also occurs if you right click Trash in side pane even if empty.

This window might be busy and is not responding.
Do you want to terminate the application?

Once Thunar has locked and terminated the icons do not work on the desktop nor does right click on the desktop. You can still run Thunar from the start menu or a launch icon in the panel.

David (david-9ei9nyjpwdex) wrote :

I have installed PCManFM 1.1.2 and that has the same issue. Crashes when trying to access the Trash folder.

David (david-9ei9nyjpwdex) wrote :

Another bit of Info. Switching the side pane from shortcuts to Tree locks/freezes the window. I had to use settings editor to switch it back to shortcut view. Seems the bug is not so much the manager but something more under lying. I am not a dev BTW.

affects: xubuntu-meta (Ubuntu) → thunar (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunar (Ubuntu):
status: New → Confirmed
Elfy (elfy) wrote :

Can confirm all of that.

Simon Steinbeiß (ochosi) wrote :

I can confirm the issue and it happened straight after upgrading to gvfs (and I quote from the changelog: "* New upstream bug fix release.").

The version I'm on now and that is causing these issues is 1.18.1-0ubuntu1.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed
Changed in pcmanfm (Ubuntu):
status: New → Confirmed
Simon Steinbeiß (ochosi) wrote :

FWIW, I downgraded to gvfs 1.18.0-0ubuntu1 and the bug disappeared, so the culprit is quite certainly gvfs.

Did a clean install of the most recent daily to disk. Tested both PCManFM & Thunar. Sadly was able to reproduce. Installed and tested Xfe which does not depend upon GVFS. Xfe does not exhibit faulty behavior but also does not utilize GVFS.

This may need to be upgraded to CRITICAL. After the file manager fails out, interacting with files on the desktop is impaired as code is left around that did not cleanly expire with the previous kill.

I am now left wondering what changed between the commits Martin Pitt made on September 24th and September 27th. We gotta get this fixed for release.

summary: - Thunar 1.6.3 under xubuntu 13.10 beta2 locks when browsing Trash
+ Thunar 1.6.3 locks when browsing Trash with Xubuntu 13.10 Beta 2 and
+ following dailies
hardboot (hardwareguy) wrote :

Not only do I get this with Thunar; PCManFM and Nemo do it to me as well.
This seems to be an underlying bug affecting GTK FMs, I haven't had it happen in kubuntu 13.10, maybe just lucky there.
This can screw up file active file operations occasionally.

Pasi Lallinaho (knome) on 2013-10-01
Changed in thunar (Ubuntu):
importance: Undecided → Critical
importance: Critical → Undecided
Changed in gvfs (Ubuntu):
importance: Undecided → Critical
Martin Pitt (pitti) wrote :

Any chance you can confirm that downgrading to gvfs 1.18.0 fixes this again, i. e. that the regression is in 1.18.1? You can get the old binaries from, click on your architecture, download the debs and install them with "sudo dpkg -iO *.deb".

Once that's confirmed, we need to find out which particular commit broke it. There aren't too many relevant ones between .0 and .1, the most plausible one is . Perhaps nautilus and thunar use the gvfs API differently so that the lock doesn't happen in GNOME (trash works fine here). Any chance that you could try to reverse-apply that patch, build, and check if the lock goes away?

Simon Steinbeiß (ochosi) wrote :

@pitti: Not sure you read my comments (#6,#9), but I already confirmed exactly that.

Martin Pitt (pitti) wrote :

Ah, thanks; so next step is to revert that one commit and see if that triggered the change. (Someone who can reproduce the bug)

It's basically this commit series which is responsible for the 1.18.1 "bug fix" release of gvfs.

Martin Pitt (pitti) wrote :

Thanks Thaddaeus.

kura (dash29-free) wrote :

I have the same thing and also with the "network" I can't check my network disk, thunar freeze and the popup to force close appaer

A new version of gvfs is available upstream containing a fix to resolve this issue:

Major changes in 1.18.2
* Fix a client side regression in 1.18.1 where apps would stop responding
* Fix a race condition in job handling that could cause large copies to hang
* Various fixes to the fuse implementation

Changed in gvfs (Ubuntu):
status: Confirmed → Fix Committed
Changed in gvfs:
importance: Undecided → Unknown
status: New → Unknown
Changed in gvfs (Ubuntu):
status: Fix Committed → Confirmed
Changed in gvfs (Ubuntu):
importance: Critical → High
status: Confirmed → In Progress
Changed in gvfs:
importance: Unknown → Medium
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.18.2-0ubuntu1

gvfs (1.18.2-0ubuntu1) saucy; urgency=low

  * New upstream version:
    - Fix a client side regression in 1.18.1 where apps would stop responding
      (lp: #1231978)
  * debian/patches/git_fix_hanging_jobs.patch:
    - dropped, it's in the new version
 -- Sebastien Bacher <email address hidden> Thu, 03 Oct 2013 16:50:49 +0200

Changed in gvfs (Ubuntu):
status: In Progress → Fix Released
Adolfo Jayme (fitojb) on 2013-12-15
no longer affects: pcmanfm (Ubuntu)
no longer affects: thunar (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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