GNOME Bugzilla – Bug 660595
Windows partition classified as "Removable Device"
Last modified: 2012-06-20 14:16:15 UTC
GNOME shell shows my Windows 7 partition as a "Removable Devices" [sic], see http://people.freedesktop.org/~david/gnome32-removable-device-bug.png which looks somewhat weird given that it's on partition in the SSD that sits deep inside my workstation. I absolutely cannot remove this device so listing it under "Removable Devices" is pretty weird. Relevant debug output in [1]. Unfortunately it's not very easy to fix this since http://developer.gnome.org/gio/unstable/GDrive.html#g-drive-is-media-removable only returns TRUE if the media itself is removable - in particular it returns FALSE for devices that people think of as "removable" (e.g. harddisks in USB enclosures). We could introduce g_drive_is_media_hotpluggable() but there is no reliable way to implement this. The best possible guess, if we want to go down this road (but I don't think we do), is to look at how the device is connected, e.g. we classify removable as removable = g_drive_is_media_removable (drive) || drive_is_connected_via_usb (drive) || drive_is_connected_via_firewire (drive) || ... ; but even this may break in virtualized environments or when tunneling USB over the network (think virtualized desktops, spice etc) or when using USB internally in the system. Conclusion: the best option is just to avoid using words such as "Removable Devices" since there is no way we can ever reliably determine if the user can easily "remove" the device or not. Hence, suggest to rephrase this. $ gvfs-mount -li Drive(0): 80 GB Solid-State Disk Type: GProxyDrive (GProxyVolumeMonitorGdu) ids: unix-device: '/dev/sda' themed icons: [drive-harddisk-ata] [drive-harddisk] [drive] is_media_removable=0 has_media=1 is_media_check_automatic=0 can_poll_for_media=0 can_eject=0 can_start=0 can_stop=0 start_stop_type=unknown Volume(0): System Reserved Type: GProxyVolume (GProxyVolumeMonitorGdu) ids: unix-device: '/dev/sda3' uuid: 'CC5888C05888AAB2' label: 'System Reserved' themed icons: [drive-harddisk-ata] [drive-harddisk] [drive] can_mount=1 can_eject=0 should_automount=0 Volume(1): Windows 7 Type: GProxyVolume (GProxyVolumeMonitorGdu) ids: unix-device: '/dev/sda4' uuid: 'E03CA0A33CA07666' label: 'Windows 7' themed icons: [drive-harddisk-ata] [drive-harddisk] [drive] can_mount=1 can_eject=0 should_automount=0 Mount(0): Windows 7 -> file:///media/Windows%207 Type: GProxyMount (GProxyVolumeMonitorGdu) default_location=file:///media/Windows%207 themed icons: [drive-harddisk-ata] [drive-harddisk] [drive] can_unmount=1 can_eject=0 is_shadowed=0 Drive(1): CD/DVD/Blu-Ray/HDDVD Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) ids: unix-device: '/dev/sr0' themed icons: [drive-optical] [drive] is_media_removable=1 has_media=0 is_media_check_automatic=1 can_poll_for_media=1 can_eject=0 can_start=0 can_stop=0 start_stop_type=unknown Drive(2): CD/DVD Drive Type: GProxyDrive (GProxyVolumeMonitorGdu) ids: unix-device: '/dev/sr1' themed icons: [drive-optical] [drive] is_media_removable=1 has_media=0 is_media_check_automatic=1 can_poll_for_media=1 can_eject=0 can_start=0 can_stop=1 start_stop_type=shutdown
Adding Jon and Cosimo
(In reply to comment #0) > Conclusion: the best option is just to avoid using words such as "Removable > Devices" since there is no way we can ever reliably determine if the user can > easily "remove" the device or not. Hence, suggest to rephrase this. That's not only a phrasing problem: if you can't remove that device, is there a point in showing it in that area at all? Does it appear in Nautilus too, with "Remove safely" in the context menu? Often, this problem is mitigated by the fact that internal disks are in /etc/fstab, and only mountable by root. Could that be used as a criterion?
(In reply to comment #2) > (In reply to comment #0) > > Conclusion: the best option is just to avoid using words such as "Removable > > Devices" since there is no way we can ever reliably determine if the user can > > easily "remove" the device or not. Hence, suggest to rephrase this. > That's not only a phrasing problem: if you can't remove that device, is there a > point in showing it in that area at all? Does it appear in Nautilus too, with > "Remove safely" in the context menu? > > Often, this problem is mitigated by the fact that internal disks are in > /etc/fstab, and only mountable by root. Could that be used as a criterion? I believe it's just a phrasing problem - e.g. we already have mechanisms for only showing mounts and mount points in /media, $HOME (and now also $XDG_RUNTIME_DIR = /run/user/davidz) so this is fine (and historically this turned out to work great - it's easy to understand for users and admins). Anyway, typically people will run into this only with a Windows partition (or a partition from another Linux distro) ... I don't think it's worth the complexity to try to hide this from the applet in the shell - we'll just cause more harm than good (e.g. hiding the wrong devices). But I do think it would help a lot if we renamed this to e.g. "Storage Devices" or just "Devices" or even "Drives" or "Disks" or "Storage". Naming is hard.
(In reply to comment #3) s). > Anyway, typically people will run into this only with a Windows partition (or a > partition from another Linux distro) ... I don't think it's worth the > complexity to try to hide this from the applet in the shell - we'll just cause > more harm than good (e.g. hiding the wrong devices). Maybe you're right, but in the precise case of Windows/other Linux distro partitions, I think it would be good to find a mechanism to hide them from that notification by default. Personally, I've put them in /etc/fstab to make them disappear. I think that's what most users would expect, as seeing your Windows partition next to your USB key is just noise. > But I do think it would help a lot if we renamed this to e.g. "Storage Devices" > or just "Devices" or even "Drives" or "Disks" or "Storage". Naming is hard. In Nautilus, they are called "Devices", which is broad enough.
(In reply to comment #4) > Maybe you're right, but in the precise case of Windows/other Linux distro > partitions, I think it would be good to find a mechanism to hide them from that > notification by default. Personally, I've put them in /etc/fstab to make them > disappear. I think that's what most users would expect, as seeing your Windows > partition next to your USB key is just noise. FWIW, I disagree that it's noise - and if you are dual-booting, chances are that you need to get a file from the other OS. Btw, in most setups we don't automount the Windows or other-Linux partition _anyway_ (it has should_automount=0) so you would rarely see it. > > But I do think it would help a lot if we renamed this to e.g. "Storage Devices" > > or just "Devices" or even "Drives" or "Disks" or "Storage". Naming is hard. > In Nautilus, they are called "Devices", which is broad enough. Could be, yeah.
(In reply to comment #0) > GNOME shell shows my Windows 7 partition as a "Removable Devices" [sic], see > > http://people.freedesktop.org/~david/gnome32-removable-device-bug.png > > which looks somewhat weird given that it's on partition in the SSD that sits > deep inside my workstation. I absolutely cannot remove this device so listing > it under "Removable Devices" is pretty weird. Relevant debug output in [1]. > > Unfortunately it's not very easy to fix this since > > http://developer.gnome.org/gio/unstable/GDrive.html#g-drive-is-media-removable > > only returns TRUE if the media itself is removable - in particular it returns > FALSE for devices that people think of as "removable" (e.g. harddisks in USB > enclosures). We could introduce g_drive_is_media_hotpluggable() but there is no > reliable way to implement this. The best possible guess, if we want to go down > this road (but I don't think we do), is to look at how the device is connected, > e.g. we classify removable as > > removable = g_drive_is_media_removable (drive) || > drive_is_connected_via_usb (drive) || > drive_is_connected_via_firewire (drive) || > ... ; Virt aside E-SATA makes this void anyway. You cannot reliably detect whether it is internal or external SATA.
(In reply to comment #5) > FWIW, I disagree that it's noise - and if you are dual-booting, chances are > that you need to get a file from the other OS. That's an argument to show the partition in Nautilus, indeed; but in the message tray? It would mean there's an icon there all of the time which doesn't indicate a transient state at all. That kinda breaks the design.
It is worth noting that this problem also exists for a dm-crypt/LUKS mounted /home (I suspect for any dm-crypt/LUKS mounted partitions). In my case, "73 GB Filesystem" is shown under devices in nautilus and in the removable devices notification.
Had a chat with David about this (echoing an early conversation with Cosimo). The way I view the notification is threefold: * Feedback for user initiated action (device was recognized after being physically connected) * An opportunity to offer the user to act on the device (the likelihood the user wants to use something they just attached is high - and we're poor at guessing what that action should be) * A way to provide the recommended reciprocal action (eject. Though we should endeavor to match the user's model where the reciprocal of attach is "yank out") None of these really apply to things that are added as a artifact of automount during system boot or session login. So, we shouldn't really be showing notifications until after the session has reached a steady state (the "ready" phase of the session). I think this will as a side effect mitigate or eliminate the case where always attached drives are identified as removable media.
(In reply to comment #9) > > I think this will as a side effect mitigate or eliminate the case where always > attached drives are identified as removable media. Yes with it just as broken and confusing. Lets say you have an sd card plugged in at login it does not show up so you have to unmount it in nautilus. When plugging it in after login you have the option to do this from the messagetray.
*** Bug 662242 has been marked as a duplicate of this bug. ***
I'm not entirely sure my bug's actually a dupe of this. a summary of mine is that an NFS mount *in my home dir* - /home/adamw/irclogs - is considered a removable device and gets hotplug notifications, which are useless. I could mount this outside my homedir, I guess, but I don't want to. In my homedir makes sense, actually, as the data involved is personal to my user: it's my irc logs, shared from the irc proxy machine which does IRC for me.
(In reply to comment #12) > I'm not entirely sure my bug's actually a dupe of this. Well the bug is "non removable media / mounts are detected as removeable" ... which is the issue here and your NFS case.
(In reply to comment #10) > (In reply to comment #9) > > > > I think this will as a side effect mitigate or eliminate the case where always > > attached drives are identified as removable media. > > Yes with it just as broken and confusing. Lets say you have an sd card plugged > in at login it does not show up so you have to unmount it in nautilus. If the device is plugged-in/mounted at login-time / boot-time then the device is either - part of the system (in one way or another); or - plugged-in/mounted by another user (think f-u-s) and the three bullet points from comment 9 does not apply. So it actually makes a ton of sense to _not_ show it and not even mount it ... especially in the f-u-s case. You can now say that the third case (e.g. in addition to the two above) is that the user plugged in the card and then booted up the system / logged in to get data from it ... but I'd argue this does not happen so often so it's not worth covering. > When > plugging it in after login you have the option to do this from the messagetray. I think it's fair to say this: _Only_ if you plug the device in while being logged in there's a 99% chance that you want to just pull data from it and then remove it (e.g. the three bullet points in comment 9). Hence, we should only add things to the "Removable Devices" icon in the message-tray and show notifications in response to detecting that you plugged in a device (and we managed to successfully automount the device in response to that). It just makes a lot more sense that what we're doing today.
Another thing to consider is that the message tray is really about differential state rather than absolute state. For example when you login we don't really want to show you a list of all messages in your mail inbox. You go to your mail app for that. But we may want to show you messages you get during the operation of the system or app (ie. changes). Likewise I don't think we need to provide the only place where you can access apps that act on removable media or the only place where you can go to eject/remove them.
(In reply to comment #15) > Another thing to consider is that the message tray is really about differential > state rather than absolute state. For example when you login we don't really > want to show you a list of all messages in your mail inbox. You go to your mail > app for that. But we may want to show you messages you get during the operation > of the system or app (ie. changes). Likewise I don't think we need to provide > the only place where you can access apps that act on removable media or the > only place where you can go to eject/remove them. Indeed that makes sense.
(In reply to comment #15) > Likewise I don't think we need to provide > the only place where you can access apps that act on removable media or the > only place where you can go to eject/remove them. OTOH I fear it would create a terrible inconsistency. People would plug in their USB keys, use the notification to open it in Nautilus, put files, go to the message bar to reopen it later if needed, and use it to eject it when done. OK, most common case. Now, if you don't eject it before rebooting the computer, what happens? "My USB key has disappeared! It's not where it used to be." Remember, for most people, the message bar will be THE place to manage removable devices, Nautilus being only a second, obscure choice. Users will think GNOME doesn't recognize USB keys if plugged before starting the computer. Technically, I think it wouldn't be too hard to distinguish a removable drive that's already plugged in when logging in, and another mount that shouldn't be shown because it's not a removable device. AFAIK, removable drives are mounted automatically by a user daemon, contrary to other mounts we don't want to show, like NFS, which are in /etc/fstab.
*** Bug 664507 has been marked as a duplicate of this bug. ***
We missed the boat for 3.4 with this feature. Cosimo: any chance we can implement this (e.g. the proposal summed up in last paragraph of comment 14) for 3.6? (It's a little jarring how it works now, for example, I get a Shell notification if I mount a device from Nautilus...)
Btw, I just fixed a gvfs bug so should_automount is set to TRUE at login time (if applicable), see http://git.gnome.org/browse/gvfs/commit/?id=e30a67f3215d829e95ee7e358c67af7d67635fe8 so now the shell mounts devices at login time, as expected. (I used to have the position that we shouldn't automount devices at login time but have since reversed.) Anyway, long story short, this bug-fix makes this particular bug even more jarring... you now get a lot of notifications at login time and the "Removable Devices" tray item is getting filled up. Maybe for 3.4 we just want to disable the notifications at login time, still waiting for an answer for what to do in 3.6?
This issue also appears if you have multiple devices as part of a single btrfs filesystem. I have three drives as part of a btrfs volume and two of them appear as "Devices" in nautilus. I assume the third does not because it is referenced in fstab to do the mount.
Note that btrfs with multiple devices is likely to "look funny" (insofar that you can expect duplicate icons) until we get more info from the kernel - last I checked, we didn't have enough information http://comments.gmane.org/gmane.comp.file-systems.btrfs/2851 and I've been checking routinely since then (I think last I checked was when talking to Josef Bacik at Plumbers 2011) but nothing changed I think... single-disk btrfs still works thanks to this hack: http://cgit.freedesktop.org/udisks/tree/src/udisksmountmonitor.c?id=1.97.0#n440
Created attachment 216769 [details] [review] autorun: change logic for ignoring volumes Previously, a volume was being ignored from autorun if one of these two conditions were met: - its mount root file had a native scheme and was mounted in a non-hidden location - it had a volume that could have been automounted, and had a flag set by the shell to allow autorun In order to effectively ignore volumes that we don't mount ourselves from our notification system, we have to meet both conditions at the same time instead.
Created attachment 216770 [details] [review] autorun: simplify code Split autorun conditions into separate logic blocks instead of a single huge if.
Created attachment 216771 [details] [review] autorun: only obey allowAutorun flag for transient notifications Only apply the allowAutorun flag for transient notifications, not for mounts that end up in the resident notification well. Also, stop looking at volume.can_automount() here, since we already checked that previously in the mounter, and allowAutorun is enough.
Created attachment 216772 [details] [review] automount: don't allow autorun for things we mount at startup We don't want to potentially flood the user with notifications about mounts when starting up the system.
Review of attachment 216769 [details] [review]: Sure.
Review of attachment 216770 [details] [review]: Sure.
Review of attachment 216771 [details] [review]: s/can_automount/should_automount/ in commit message?
Review of attachment 216772 [details] [review]: Sure.
Attachment 216769 [details] pushed as 0e3795b - autorun: change logic for ignoring volumes Attachment 216770 [details] pushed as ebee01b - autorun: simplify code Attachment 216771 [details] pushed as cbb8d5b - autorun: only obey allowAutorun flag for transient notifications Attachment 216772 [details] pushed as 646435e - automount: don't allow autorun for things we mount at startup