"Eject" and "Unmount"

[Brian J. Tarricone]

On Thu, 12 Feb 2009 08:28:18 +0100 Yves-Alexis Perez wrote:

> On mer, 2009-02-11 at 23:21 -0800, Brian J. Tarricone wrote:
> > 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.
> > 
> > thunar_vfs_volume_is_ejectable() should NOT correspond to
> > storage.requires_eject. 
> 
> It was like this before and this proved to be buggy.

You're gonna need to explain that a bit further.  What was buggy about
it?

> >  Just because a volume doesn't *require* eject,
> > it doesn't mean that it's not ejectable.
> 
> But some of theme are.

Huh?  What devices that are not marked storage.requires_eject=true will
do horrible things when you try to eject them?  Note that I'm not
advocating simply ejecting everything when the user wants to remove
something.  All volumes should first be explicitly unmounted, and then
the underlying storage device should be ejected.

> > 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.
> 
> Why so?

We've discussed this to death before on this list and on thunar-dev,
and I just repeated myself in another post a few minutes ago.  Feel
free to read that.

> > Ejecting normal USB media is entirely safe and probably a good idea
> > (after unmounting), even if storage.requires_eject is false.
> 
> No. If you look at the bug report, we had some people with devices
> which were failing when ejected.

No, that's not what's happening at all.  Well, it is, but that's not
the bug.  The bug is that it wasn't first doing an unmount before the
eject.  And if it was, but the eject was failing (while the mount was
succeeding) the eject error can be safely ignored.

> And really “ejecting” doesn't make
> any sense for most of the device, and should be opt-in (thus the hal
> key).

No, the HAL key only specifies devices that *require* an eject, in the
sense that if you physically remove the device without first ejecting
it, you can damage it or lose data (even if you've done an unmount).
This *does not* mean that requires_eject=false means that you
*shouldn't* eject the device, only that it's not required to ensure
data integrity.

> If we use eject by default we would need an “dont_eject” key in
> hal for unsupported devices.

Yes, broken devices that respond poorly to an eject *should* be
blacklisted by HAL.  Because yes, a USB mass storage device that gives
an error is indeed broken.  But it's not in the HAL spec, and personally
I have little interest in trying to fix that (and apparently the HAL
developers are abandoning HAL to work on their latest new shiny toy,
DeviceKit, so I imagine they wouldn't care to add it anyway).

But still, regardless of how thunar_vfs_volume_is_ejectable() behaves,
we shouldn't be displaying "Mount"/"Unmount" in the UI at all, for the
reasons I've cited elsewhere.

	-brian