What does eject do on non-ejectable volumes? Can we know if it will do anything sane at all?

We also have a related problem in the UI, we currently only show the eject operation if both eject and unmount are possible. This is because its not that easy to understand the difference, although people are requesting to add the unmount menu item too.

If we add eject to all sorts of volumes we won't get any unmount operation for them unless we always show both unmount and eject.

Whats your opinion on showing both?

As I said, the case where I found I need eject is having multiple partitions on a usb stick that I want to pull. If we had a representation of the stick as a whole somewhere, we could put a menuitem on that, but we don't...

(In reply to comment #1)
> What does eject do on non-ejectable volumes? Can we know if it will do anything
> sane at all?

There are two answers to this question

First, in GVfs g_[drive,volume,mount]_eject() ensures that all mounts of the drive is unmounted; then the eject command is sent to the device. If one of the mounts are busy the operation fails with G_IO_ERROR_BUSY. Only when all volumes are unmounted, we then send the eject command to the device via DeviceKit-disks via eject(1).

The eject command itself is describe in the man page for eject(1). In a nutshell it involves sending a special command to the device. eject(1) takes care of the details, e.g. the command varies depending on the command set used to speak to the device.

If the device reports having removable media (attr 'removable' in sysfs is 0) then, AFAICT from the specs, nothing happens. OTOH, if the device reports having removable media [1] then what happens when sending the eject command to the target is that it will appear as the media is removed. E.g. the host can no longer address the device.

There are two interesting side effects here

 1. Basically, in order to use the device again, you will have to replug it

 2. iPod/Kindle/others will stop serving data and the "Device is not safe
    to remove"-ish banners will go away

Historically in GNOME we have used a white-list to determine which devices are "ejectable" e.g. if we should send a eject command when the last volume is unmounted. This white-list has included a ton of iPod and related devices. Of course we're always out of date (since there are tens of thousands of devices) so it turns out this isn't really working well.

[1] : and mind you, 99.9% of all usb sticks report to have removable media even when they don't.. ditto for iPod/Kindle/others that requires the user to "eject" them before they are "safe to remove" [sic]

> We also have a related problem in the UI, we currently only show the eject
> operation if both eject and unmount are possible. This is because its not that
> easy to understand the difference, although people are requesting to add the
> unmount menu item too.
> 
> If we add eject to all sorts of volumes we won't get any unmount operation for
> them unless we always show both unmount and eject.
> 
> Whats your opinion on showing both?

From a user interface point of view I think we really only want to have the "Eject" metaphor and always use g_mount_eject() instead of g_mount_unmount().

Let us look at the pros and cons of this proposal

Pros

 P1. The UI is less confusing. The verb "Eject" is well-known both
     from OS X / iTunes and also recent versions of Windows. We can
     get totally rid of the "Unmount" concept in the core shell UI.

 P2. We don't need a white-list and the whole "device is safe to remove"-ish
     banner problem is solved

 P3. For removable devices with multiple partitions (and the only really
     sane use case here is a USB stick with a cleartext and an encrypted
     partition) the natural thing happens. The device is safe to remove
     after the user having clicked "eject"

Cons

 C1. Users with removable devices with multiple partitions might be
     surprised that we unmount all the partitions and render the device
     unusable until next plug-in.

My view is that users getting annoyed at C1. can use other tools (gvfs-mount, palimpsest, /etc/fstab and mount(1)) to do their thing.

We can of course mitigate this by showing both "Unmount" and "Eject" in the context menus (perhaps this could be configurable via gconf and we would default to only showing eject). But the core UI, e.g. the Nautilus sidebar would default to Eject for the Eject icon.

As a data point OS X works like this except that they don't have the concept of Unmount in the core UI. That option is however available in the Disk Utility application.

I think we should make this change for 2.28.

I'm not sure what you're proposing here exactly.

The UI always says "Eject", unless you've set some gconf option to show a separate unmount item. But, what should the Eject command do?

Do you mean:

if (g_mount_can_eject())
  g_mount_eject(mount);
else
 g_mount_unmount(mount);

What I'm proposing is that

 - We change the volume monitor in GVfs such that all GVolume and GMount
   objects associated with a GDrive always report that they can eject;
   e.g. g_[drive|volume|mount]_can_eject() returns TRUE

 - For a GMount for which g_mount_eject()->TRUE we make Eject the default
   action in both the file manager, the file chooser and other GIO using
   apps (I think it is this way already)

See comment 3 for pros and cons of this approach.

As a data point I think Ubuntu used to do this for at least a while (by merging a fdi file that was setting .can_eject on HAL).

Also see bug 574067.

Here's the patch to do this

http://cgit.freedesktop.org/~david/gvfs/commit/?h=gdu-volume-monitor&id=303cfd43578f0a4198c063f1a5fbcd16fec2b0bf

However in order for this to be useful, the Nautilus patch in the bug referenced in comment 6 needs to be reverted.

Without this patch there is no Eject option in the GUI for my Kindle device (despite the device saying "please eject your kindle from your computer") so this is really a net win.

Ok, I buy that we need to allow all (or at least most, i.e. all removable) mounts to can_eject. And since that has additional semantics (unmounts all mounts on drive) we also need to expose a separate unmount operations for those cases.

There is still the question about how to present this in the UI.

There are three cases, and the first two are pretty obvious:

1) !can_unmount & can_eject
Only show eject
2) can_unmou & can_eject
Show both

However, the third has two possibilities:
3) can_unmount & !can_eject
The traditional way would be to call the single menu item for this "unmount", but if we want to make "eject" the primary operation we could call it "Eject" in the menu but still do an unmount in the code. 

I'm not sure what is best. If we eventually want to get rid of having two menu items (maybe make it a gconf setting to show the unmount item) then making case 3 say "eject" is the right approach. However, if getting rid of unmount is not a good idea (since its a useful op) labeling it as eject seems to increase confusion.

I think at this point we should go with having both menu items and thus calling case 3 "unmount", because this, while perhaps unnecessarily complex to some, is the most safe way (allows all ops) and is most unlikely to cause usecase problems we didn't think of (which is nice this late in the cycle).

If we want to do anything smarter we can do that next cycle.

Hey Alex,

I agree with comment 8. I wrote up a short analysis, see below, of how this will impact user-experience (that is, trying to figure out what kind devices falls into 1), 2) and 3)) and I think it looks reasonable.

==

Right now can_unmount is always TRUE so 1) is empty right now. However, for GDrive with removable media and only a single user-visible [0] GVolume we could probably set can_unmount==FALSE and can_eject==TRUE. Then we'd only show Eject for those. Devices that fall into this category include

 - non-mixed optical discs (ie. 99% of all discs)
 - consumer electronics like iPod/Kindle
 - usb sticks with a single partition (the norm)

which I think is the user experience we want. So I think these devices fall under 1): Only show Eject.

Devices with more than a single user-visible GVolume typically include

 - mixed optical discs (both audio and data)
 - multiple partitions on a USB stick: for example one cleartext and one LUKS partition
 - the system drive (/, /boot, swap, whatever)

This is case 2): we show both Unmount and Eject.

Normal hard disks and USB enclosures (e.g. a real SATA hard disk connected via a USB bridge) are typically not removable [1] and users tend not to carry them around as they are rather bulky and don't easily fit in a pocket. Typically people use it for permanent expansion for non-laptop systems. So it is probably fine to just show Unmount for these even if they only sport a single user-visible GVolume. That's case 3): Only show Unmount.

[0] : For example, iPods typically have two partitions; a data partition (which is vfat or hfs+) and a firmware partition (no known fs signature). We only show the former so for all intents and purposes this disk is treated like it only has one partition.

[1] : USB devices w/o removable media get a different icon too, e.g. USB devices with removable media get the icon for "Sandisk Cruzer" in http://people.freedesktop.org/~david/bgo576929-3.png (blue USB logo on top of a removable drive) while USB devices without removable media get the icon for "500 GB WD 5000KS External" in http://people.freedesktop.org/~david/gdu-multiple-mount-points.png (grey USB logo on top of a hard disk). This is intentional as USB devices without removable media are typically just as fast / large as normal hard disks.

I disagree on one thing, which is implementing "only show eject" by unnecessarily setting can_unmount to false even though we can unmount. I'd like it to be programatically possible to unmount, even if we don't expose that in the UI.

nautilus now shows both operations.

(In reply to comment #10)
> I disagree on one thing, which is implementing "only show eject" by
> unnecessarily setting can_unmount to false even though we can unmount. I'd like
> it to be programatically possible to unmount, even if we don't expose that in
> the UI.

I think g_mount_unmount() works despite g_mount_can_unmount() returns FALSE. But, yea, it's not very nice.

OK, so how about hardcoding that behavior in Nautilus? Actually there's a TODO item in src/nautilus-places-sidebar.c that says "TODO: hide unmount if the drive only has a single mountable volume".

Let me see if I can come up with a patch...

Created attachment 132538 [details] [review]
Proposed Nautilus patch

Here's a patch to implement the proposal in the previous comment.

Created attachment 132539 [details] [review]
Better patch

Here's a better patch that also does the right thing for menus (both popup menus and the File menu).

Lets hold on to such changes to next cycle and do the minimum needed now.

(In reply to comment #9)
> Hey Alex,

[...]

> Normal hard disks and USB enclosures (e.g. a real SATA hard disk connected via
> a USB bridge) are typically not removable [1] and users tend not to carry them
> around as they are rather bulky and don't easily fit in a pocket. Typically
> people use it for permanent expansion for non-laptop systems. So it is probably
> fine to just show Unmount for these even if they only sport a single
> user-visible GVolume. That's case 3): Only show Unmount.

Maybe not always, but I have a 2.5" USB (and eSATA) enclosure that I
specifically got to carry around.  I use it to carry my data to work
when I bike, as I don't want to bring my laptop in.

In fact, I have three removable hard disks that regularly are attached
to my laptop, and each of them are "removable":

1/ a 3.5" backup disk, which is ony attached when I need to backup
2/ the 2.5" disk
3/ a disk in a Lenovo Ultrabay, which is removed when I need to use the
   CD/DVD device

For each of them the eject semantics are more appropriate than the
unmount semantics, as

1/ I want all partitions unmounted when the physical drive is removed
2/ turning off the disk (if possible) is better for removal than just
   unmounting

[...]

Peter F. Patel-Schneider

(In reply to comment #16)
> In fact, I have three removable hard disks that regularly are attached
> to my laptop, and each of them are "removable":

They are not. Be careful here with not conflating the terms. In this discussion, "Removable" means "device is using removable media". You are referring to the fact that the device is on a hotpluggable bus such as USB, Firewire and SATA.

> 1/ a 3.5" backup disk, which is ony attached when I need to backup
> 2/ the 2.5" disk
> 3/ a disk in a Lenovo Ultrabay, which is removed when I need to use the
>    CD/DVD device
> 
> For each of them the eject semantics are more appropriate than the
> unmount semantics, as
> 
> 1/ I want all partitions unmounted when the physical drive is removed
> 2/ turning off the disk (if possible) is better for removal than just
>    unmounting

As I explained on the nautilus-list we have no way to determine these things.

     David

Just FYI, I just committed some code to GVfs that will also show the Eject option for USB enclosures that contains disks that are not removable, e.g. real spinning hard disks (previously we didn't show the Eject option). 

The action that will take place when Eject fires (e.g. by clicking the Eject icon in Nautilus' sidebar or by choosing Eject from the context menu) is that we'll unmount all partitions as usual. Then, instead of sending an eject ioctl to the device (which would do nothing), we send the SCSI SYNCHRONIZE CACHE and SCSI STOP UNIT commands followed by unbinding the usb-storage drive. The effect is that the drive nicely powers down (so it is silent) and the OS will react just as if you removed it (e.g. all block devices will go away).

More details here

 http://article.gmane.org/gmane.linux.hotplug.devel/14088

and in the links to commit messages in that mail (there's some corner cases that needs to be handled; the commit messages explains all that).

I'm not sure if this has been proposed yet, but this is my suggestion, if people think it's good then I'm happy to write up a patch but I don't feel like doing the work first..

What if nautilus showed devices with multiple partitions as sub-items of the device, so if I plug in my USB drive which has 3 paritions I get a top level node, the drive which when I right click has an "Eject" option, to unmount all patitions, and safely remove the drive. Each partition has an "Unmount" (or maybe we can find friendlier wording, but let's use unmount for the sake of argument) option, that will just unmount that partition but leave the device, and other partitions mounted. I'll try and make some mockups. I'm not an artist however..

Created attachment 136310 [details]
Mockup for how nautilus should handle eject/unmount for devices

The sub items would say Unmount instead of eject, not sure why the fonts dont match, either gimp is using the wrong fonts, or nautilus is. Not really the point :)

i like the mockup comment#20
it's the same idea that bug 508404

currently it's not possible to eject a blank CD would that be an issue for this bug or should a new one be opened?

While we are trying to simplify by changing unmount to "Eject" ...
Win7 now uses "Dismount" !

So , in a few years are we going to come back to "Unmount" ?

We are trying to make it easier , for average users but the same question of "Eject" will arise in a few years , and people will then say , Eject is not right! Win7 uses "Dismount" ...!

I'd say we stick with "Unmount" , and dont change anything.

Eject is not the same as unmount in the new behavior. Eject will unmount all volumes on a device, and perform necessary power off actions. We're gaining features, not merely replacing technical terms with simpler ones.

(In reply to comment #24)
> Eject is not the same as unmount in the new behavior. Eject will unmount all
> volumes on a device, and perform necessary power off actions. We're gaining
> features, not merely replacing technical terms with simpler ones.

Ah... didnt realize the difference, I've clearly misunderstood your comment on LP>
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/28835/comments/62

Wouldnt a better term be : 
"Unmount Partition" 
"Eject Drive" / "Eject Device"
Wouldnt this would make the options more easy to differentiate?
Now the options are confusing unless someone says what the options do.

That one has been fixed in 2.28, right?

Actually something is not clear to me: what does "Remove safely" does different than "Unmount"? In Ubuntu we have a bug [1] requesting to remove technical terms such as "Unmount". Even though I'm not all in favor of it, I don't understand why some external drives have "Eject", "Remove safely" and "Unmount", while some only have "Unmount". I'd have thought that "Unmount" should only be a supplementary option for advanced users, while we *always* show something easier to understand such as "Remove safely".

"Remove safely" does the same to the medium as "Eject" but additionally sends a command to the device to stop its motor, activate its power-saving or similar. One of my USB harddisk cases does support this (its harddisk stops spinning!), another one does not, and Karmics "Remove safely" therefore opened a complaining dialog.

I like the proposal of Vish in comment #25! "Eject" could do what "Remove safely" does now: implicitly send a stopping command and ignore if it fails because the hardware does not support it.

As concession to new users, it's ok that each Eject *button* in Nautilus' sidebar does eject the whole medium (all its filesystems) at once. I agree that unmounting is an advanced operation suitable for the context menu.

Gdu volume monitor has been superseded by udisks2 volume monitor long time ago. I am closing this bug because many have been changed since this was reported. If this is still an issue with the recent gvfs releases, please reopen and change component to udisks2 volume monitor.