GNOME Bugzilla – Bug 737891
mounting LUKS partition from nautilus takes very long
Last modified: 2015-03-08 22:31:27 UTC
Steps to reproduce: 1. plug a hard disk with any LUKS partition 2. open nautilus 3. in nautilus: click on the LUKS partition to open the device nautilus often takes very long until showing a password prompt or does nothing at all. this seems to happen especially after typing a wrong password on the first attempt or when gnome-disks is running. Effect: In some cases encrypted partitions cannot be mounted from nautilus. This does not happen with gnome-disks or the udisks command line utility. Using gvfs 1.22.0-1.fc21 from Fedora 21 Alpha, gnome-disks 3.12.1, udisks 2.1.3, nautilus 3.14.0.
After this happens, nautilus is unable to ever open the hard disk until you close it (exit nautilus process). Before that it tells me: Cannot access <partition name>: An operation is already pending As a workaround stopping all nautilus processes and retrying works.
Thanks for your bug report! I can't reproduce it on Fedora 20 with Gnome 3.14. Password prompt is shown immediately after device is connected (even if gnome-disks is running, or after wrong password is typed). Also reopening works like charm. Will have to test with Fedora 21.
Ok, I can reproduce it (or something similar) on Fedora 21, but it happens randomly...
Yeah, quite randomly. Seeing it now waiting for forever even when clicking on the LUKS partition for the first time (so no password prompt or some progress indication is displayed at all).
gvfs-mount -d /dev/sdb1 seems working correctly, so problem is probably somewhere in nautilus or gtk+...
I can reproduce it with nautilus 3.12 and gtk+ 3.14, but not with gtk+ 3.12. I guess something has changed in GtkMountOperation, so changing component...
This is the only change in gtkmountoperation between 3.12 and 3.14... https://git.gnome.org/browse/gtk+/commit/?id=1b9fa975af45b1723fe21a65503859609dc0e7ad
Yep, I saw it... I've made further testing and found that gtk+ version change from 3.13.1 to 3.13.2 triggers the issue for me. Do you have an idea what was changed between those versions?
Nothing jumps out. I'm afraid you may have to bisect
Ok, I've tried git bisect (pretty useful utility) and there is result: 85da29b689370d00914ca6c7c5a7bf99fbb702f is the first bad commit commit 185da29b689370d00914ca6c7c5a7bf99fbb702f Author: Carlos Garnacho <carlosg@gnome.org> Date: Thu Mar 27 12:31:28 2014 +0100 treeview: Use multipress gesture for row activation Replace custom double click detection with multipress gesture :040000 040000 7faec248766fb4f4a497b4d71ee7fb06f2147001 85fbb51c605c98955dbb6430607a4e5c5f1a7e92 M gtk This patch triggers the issue for me, but I really don't know what this commit have to do with mounting LUKS partitions (or what I am doing wrong)... Matthias, have you an idea?
gnome-shell outputs the following when it fails: gnome-session[1948]: Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed gnome-shell fails to show the modal dialog if it fails to acquire a grab (presumably because the application already has one). I can reproduce this even with GTK 3.13.1 by simply clicking and holding on the disk partition for 1/2 a second.
I stand corrected: the commit Ondrej mentions is indeed the culprit. The reason it triggers the issue is that before this commit, the row-activated signal for a treeview was emitted on button release. With this commit, the row-activated signal is emitted on button down. This behavior change causes gtk_mount_operation_new() to be executed with the button down, causing gnome-shell to fail to display the modal dialog (as I mentioned in my previous comment). Was this change in behavior intended?
Created attachment 290096 [details] [review] treeview: remove single-click activation from GtkGestureMultiPress::pressed This is already handled in GtkGestureMultiPress::release, and more in concordance with how it was done pre-gestures.
This change of behavior was certainly not intended, with the attached patch I can confirm that ::row-activated is emitted on button release as it did on <=3.13, but I don't have LUKS partitions at hand that I can mount post-boot, so testing is appreciated.
(In reply to comment #14) > This change of behavior was certainly not intended, with the attached patch I > can confirm that ::row-activated is emitted on button release as it did on > <=3.13, but I don't have LUKS partitions at hand that I can mount post-boot, so > testing is appreciated. I'll give it a test soon. Another change I noticed was that previously when double-clicking on a tree-view, it would activate on the second button-down. With the gesture changes, it activates on the second button-up. I'm not sure how much this matters; the reason that I noticed it was because I found that I had to double-click faster to treeview rows to activate.
(In reply to comment #15) > (In reply to comment #14) > > This change of behavior was certainly not intended, with the attached patch I > > can confirm that ::row-activated is emitted on button release as it did on > > <=3.13, but I don't have LUKS partitions at hand that I can mount post-boot, so > > testing is appreciated. > > I'll give it a test soon. Thanks! > Another change I noticed was that previously when double-clicking on a > tree-view, it would activate on the second button-down. With the gesture > changes, it activates on the second button-up. I'm not sure how much this > matters; the reason that I noticed it was because I found that I had to > double-click faster to treeview rows to activate. Hmm, I can't confirm that bit... ::row-activated emission on n_press=2 certainly happens only on ::pressed, I could double check this behavior by running gtk3-demo and activating a demo by double clicking on its row, but keeping the button pressed longer on the second click (demos activate on ::row-activated), the demo is activated despite the second button release not arriving yet.
I've freed an usb stick here and created a LUKS partition, I can confirm this is fixed with the patch in comment #13. I'm pushing to master and gtk-3-14 and closing this.
Attachment 290096 [details] pushed as 4df13b7 - treeview: remove single-click activation from GtkGestureMultiPress::pressed
(In reply to comment #16) > (In reply to comment #15) > > Another change I noticed was that previously when double-clicking on a > > tree-view, it would activate on the second button-down. With the gesture > > changes, it activates on the second button-up. I'm not sure how much this > > matters; the reason that I noticed it was because I found that I had to > > double-click faster to treeview rows to activate. > > Hmm, I can't confirm that bit... ::row-activated emission on n_press=2 > certainly happens only on ::pressed, I could double check this behavior by > running gtk3-demo and activating a demo by double clicking on its row, but > keeping the button pressed longer on the second click (demos activate on > ::row-activated), the demo is activated despite the second button release not > arriving yet. Thanks for fixing the original bug. Also, I can't reproduce this other behavior I thought I was seeing anymore, but thanks for looking into it.