"Eject" and "Unmount"

[Brian J. Tarricone]

Jannis Pohlmann wrote:
> Am Wed, 11 Feb 2009 23:21:42 -0800
> schrieb "Brian J. Tarricone" <bjt23 at cornell.edu>:
> 
>> On Thu, 12 Feb 2009 07:47:40 +0100 Yves-Alexis Perez wrote:
>>
>>> On jeu, 2009-02-12 at 14:03 +0800, Shou-Lien Chen wrote:
>>>> hello all:
>>>> According to
>>>> http://www.xfce.org/documentation/api/thunar-vfs/ThunarVfsVolume.html#thunar-vfs-volume-is-ejectable
>>>> The thunar_vfs_volume_is_ejectable () should return TRUE only if a
>>>> medium is present and the volume is removable Is this mean it
>>>> reference the hal key: storage.removable = true  ? I found my usb
>>>> disk and sd card is treat as "reject" if I want remove them, but
>>>> there is a storage.requires_eject = false key  found if I monitor
>>>> my usb disk by lshal command
>>>>
>>>> Thus, which hal key is referenced by the thunar-vfs lib to judge
>>>> if a volume need to be eject or unmount?
>>> http://bugzilla.xfce.org/show_bug.cgi?id=3978
>> Jannis, can you explain this change a bit better? Unless I'm
>> misunderstanding, that fix is incorrect.
> 
> Well, what we had before was:
> 
>   /* check if HAL drive requires eject */
>   if (THUNAR_VFS_VOLUME_HAL (volume)->requires_eject)
>     return TRUE;
> 
>   /* otherwise we can only eject removable media, that are present
>      (surprise, surprise) */
>   return (thunar_vfs_volume_is_present (volume) 
>           && thunar_vfs_volume_is_removable (volume));
> 
> which basically displayed the eject button for all mounted devices such
> as USB sticks, CD drives etc. However, you can't eject USB sticks,

Sure you can.  Try "eject -v /dev/sda" as root sometime (assuming sda is 
a USB mass storage device) and see what happens.  I've actually never 
seen that fail on any UMS device, though apparently there are a few that 
are broken (as in the bug report).

> at least not with thunar_vfs_volume_hal_eject() which calls exo-eject ...
> which fails.

Not sure what you mean; this has always worked fine for all my devices.

> Too bad that almost no API docs for HAL exist. I think this change
> works fine but I agree with you: "requires" and "supports" are two
> different things.

Well, there's the incomplete HAL spec, which tends to change with each 
minor (even micro) release of HAL, but that's often kinda useless.

>> thunar_vfs_volume_is_ejectable() should NOT correspond to
>> storage.requires_eject.  Just because a volume doesn't *require*
>> eject, it doesn't mean that it's not ejectable.
> 
> I know that logically these two things mean something different.
> However, requires_eject seems to be true exactly for the devices that
> *can* be ejected. At least I haven't seen a device where that was not
> the case.

Then I guess you don't have many devices.  *Every* device I have seen 
works fine when ejecting it.

>> As previously discussed, we should *not* have "Unmount" in Thunar's
>> (or xfdesktop's) UI anywhere.  Any place where we do would be
>> considered a usability bug.
>>
>> Ejecting normal USB media is entirely safe and probably a good idea
>> (after unmounting), even if storage.requires_eject is false.
> 
> Ejecting normal USB media with exo-eject will fail. Right now what we
> do is:
> 
>   1. Unmount (all devices)
>   2. Eject (only devices with requires_eject=true)
> 
> What we could do is:
> 
>   1. Unmount (all devices)
>   2. Eject and any ignore errors from exo-eject (all devices)
> 
> I doubt this is a good idea though because for some devices you
> actually want errors of exo-eject to be displayed. So, option three is:
> 
>   1. Unmount (all devices)
>   2. Eject (all devices) and ignore errors from exo-eject (only devices
>      with requires_eject=false)

Yeah, this probably makes the most sense.

The problem with not ejecting a device when you're done with it is that 
it won't disappear from Thunar's shortcuts pane (or 
xfce4-volstatus-icon's volume list).  If you only unmount a device, it 
can be somewhat confusing to users of other OSes as to whether or not it 
really is safe to remove it.  Ejecting it actually tells the kernel to 
"forget" what it knows about the device's partitions entirely.

> But since the current way of doing it seems to be fine (except for the
> mount/unmount labels, which we could change without adding new strings
> by the way) and GIO/GVfs will completely change how this works anyway,
> I'm not really interested in putting too much effort into it right now.

Yeah, good point.

	-b