GNOME Bugzilla – Bug 670452
User is not warned when ejecting removable media when files are still in use.
Last modified: 2012-06-22 14:50:29 UTC
This appears to be a regression from versions 3.0 and 3.2. I discovered this when validating the existing user documentation. This occurs in gvfs v1.11.3 To reproduce: - plug in a usb thumb drive with a picture or document on it - open the picture or document from the usb thumb drive - modify the picture or document - select "eject" from the Files file manager - remove the thumb drive Result: - the usb device is ejected without warning. - If I attempt to save the modified file after the thumb drive is removed, I get the message: Shotwell Error while saving to /run/user/jim/media/jim-file/Screenshot at 2012-02-18 20:33:37.png: Failed to open file '/run/user/jim/media/jim-file/Screenshot at 2012-02-18 20:33:37.png': No such file or directory Expected result: - I should be prompted with a window telling me that "the volume is busy", and listing all the open files on the device. Once I close all the files on the device, the device will automatically be safe to remove (so I can unplug or eject it). - dmesg | tail: [14473.603337] sd 8:0:0:0: [sdb] No Caching mode page present [14473.603349] sd 8:0:0:0: [sdb] Assuming drive cache: write through [14473.651509] sdb: sdb1 [14473.657637] sd 8:0:0:0: [sdb] No Caching mode page present [14473.657642] sd 8:0:0:0: [sdb] Assuming drive cache: write through [14473.657653] sd 8:0:0:0: [sdb] Attached SCSI removable disk [14476.080645] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [14476.080663] SELinux: initialized (dev sdb1, type ext4), uses xattr [14529.596602] sdb: detected capacity change from 2031091712 to 0 [14534.778351] usb 2-2: USB disconnect, device number 5 Please let me know if you need more information.
This is a regression we spotted while writing the documentation at the Documentation hackfest. Setting the appropriate importance.
Entering, "cat > /run/user/jim/media/jim-file/xxx.txt" at the terminal, and then attempting to unmount the device through the Files application produces: Error unmounting /dev/sdb1: Command-line `umount "/run/user/jim/media/jim-file"' exited with non-zero exit status 32: umount: /run/user/jim/media/jim-file: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))
We've been talking about this a bit in downstream Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=819492 upshot is, first of all, this isn't a gvfs bug. gvfs' function does the right thing, DavidZ says. The gvfs unmount function doesn't return until the data is synced. The problem is that at least Shell and Nautilus, and probably other apps (Shotwell springs to my mind) are calling the gvfs function and immediately returning, not waiting for gvfs to actually complete or even notifying that it's still working. So they're making it look like the disk is already unmounted immediately, there's no indication that activity is still going on. In previous versions there was a notification as described in the initial report here. That was removed because it was badly written code, apparently, it just wasn't the right way to do things. What needs to happen is that Shell, Nautilus, and anything else with the capability to unmount disks needs to implement some kind of notification or blocking until the unmount is actually complete. https://bugzilla.gnome.org/show_bug.cgi?id=619665 already exists for Nautilus, though its importance is probably higher now than when it was filed because the notification has been taken out. There's no bug for Shell yet. I'll file one.
Filed for Shell: https://bugzilla.gnome.org/show_bug.cgi?id=675627
Adam, this is a different problem - we're talking about missing UI bits of busy volume. The Fedora bug is one step further - we're able to unmount (no open files) yet missing UI bits for the sync op (or not returning before it's completed). This bugreport is still high on my todo list, been debugging this personally during Brno hackfests in February.
Just tested on git master, possibly fixed by http://git.gnome.org/browse/gvfs/commit/?id=4f89d930d3eb8414dc301262d7db448d257843bc Works with udisks-1.97.0 Closing now, feel free to reopen when the issue appears again.