After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660595 - Windows partition classified as "Removable Device"
Windows partition classified as "Removable Device"
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 662242 664507 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-09-30 20:54 UTC by David Zeuthen (not reading bugmail)
Modified: 2012-06-20 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
autorun: change logic for ignoring volumes (1.27 KB, patch)
2012-06-20 00:40 UTC, Cosimo Cecchi
committed Details | Review
autorun: simplify code (1.71 KB, patch)
2012-06-20 00:40 UTC, Cosimo Cecchi
committed Details | Review
autorun: only obey allowAutorun flag for transient notifications (1.83 KB, patch)
2012-06-20 00:40 UTC, Cosimo Cecchi
committed Details | Review
automount: don't allow autorun for things we mount at startup (2.38 KB, patch)
2012-06-20 00:40 UTC, Cosimo Cecchi
committed Details | Review

Description David Zeuthen (not reading bugmail) 2011-09-30 20:54:39 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
Comment 1 David Zeuthen (not reading bugmail) 2011-09-30 20:56:49 UTC
Adding Jon and Cosimo
Comment 2 Milan Bouchet-Valat 2011-09-30 21:00:24 UTC
(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?
Comment 3 David Zeuthen (not reading bugmail) 2011-09-30 21:12:49 UTC
(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.
Comment 4 Milan Bouchet-Valat 2011-09-30 22:00:52 UTC
(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.
Comment 5 David Zeuthen (not reading bugmail) 2011-09-30 22:09:23 UTC
(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.
Comment 6 drago01 2011-10-01 07:14:49 UTC
(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.
Comment 7 Milan Bouchet-Valat 2011-10-01 09:10:04 UTC
(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.
Comment 8 Casey Harkins 2011-10-21 13:39:53 UTC
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.
Comment 9 William Jon McCann 2011-10-21 19:06:44 UTC
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.
Comment 10 drago01 2011-10-21 19:16:23 UTC
(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.
Comment 11 drago01 2011-10-21 19:17:41 UTC
*** Bug 662242 has been marked as a duplicate of this bug. ***
Comment 12 Adam Williamson 2011-10-21 19:23:49 UTC
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.
Comment 13 drago01 2011-10-21 19:25:10 UTC
(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.
Comment 14 David Zeuthen (not reading bugmail) 2011-10-21 19:27:04 UTC
(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.
Comment 15 William Jon McCann 2011-10-21 19:34:14 UTC
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.
Comment 16 drago01 2011-10-21 19:36:36 UTC
(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.
Comment 17 Milan Bouchet-Valat 2011-10-21 20:09:30 UTC
(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.
Comment 18 Jasper St. Pierre (not reading bugmail) 2011-11-21 21:21:36 UTC
*** Bug 664507 has been marked as a duplicate of this bug. ***
Comment 19 David Zeuthen (not reading bugmail) 2012-04-09 17:49:14 UTC
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...)
Comment 20 David Zeuthen (not reading bugmail) 2012-04-18 21:47:42 UTC
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?
Comment 21 Patrick 2012-05-09 21:14:28 UTC
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.
Comment 22 David Zeuthen (not reading bugmail) 2012-05-09 21:30:49 UTC
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
Comment 23 Cosimo Cecchi 2012-06-20 00:40:19 UTC
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.
Comment 24 Cosimo Cecchi 2012-06-20 00:40:27 UTC
Created attachment 216770 [details] [review]
autorun: simplify code

Split autorun conditions into separate logic blocks instead of a single
huge if.
Comment 25 Cosimo Cecchi 2012-06-20 00:40:32 UTC
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.
Comment 26 Cosimo Cecchi 2012-06-20 00:40:38 UTC
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.
Comment 27 Jasper St. Pierre (not reading bugmail) 2012-06-20 00:48:09 UTC
Review of attachment 216769 [details] [review]:

Sure.
Comment 28 Jasper St. Pierre (not reading bugmail) 2012-06-20 00:51:41 UTC
Review of attachment 216770 [details] [review]:

Sure.
Comment 29 Jasper St. Pierre (not reading bugmail) 2012-06-20 00:53:20 UTC
Review of attachment 216771 [details] [review]:

s/can_automount/should_automount/ in commit message?
Comment 30 Jasper St. Pierre (not reading bugmail) 2012-06-20 00:54:22 UTC
Review of attachment 216772 [details] [review]:

Sure.
Comment 31 Cosimo Cecchi 2012-06-20 14:16:00 UTC
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