"Eject" and "Unmount"

[Yves-Alexis Perez]

On jeu, 2009-02-12 at 00:21 -0800, Brian J. Tarricone wrote:
> > 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?

Well you saw the bug report.
> 
> > >  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.

But it doesn't have any sense for some devices, as I understand it.
Especially things like usb stick don't have to be ejected, and it
doesn't even as a meaning for those.
> 
> > > 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.

Well, in that case, obviously the device doesn't support “ejecting” it
so why even try?

> 
> > 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).

What am I saying is that what we can rely on is hal stuff. 
Hal can say if a device *requires* an eject, but not if the devices
requries *not* to be ejected. And we know some device don't support
ejection.

So, imho, we should stick with the hal default, which is “no eject by
default, except for require_eject=true”. It's better than doing umount
+eject and silently ignoring eject errors.

But yeah it could be interesting to know if there are devices which
would spit error after an unmount+eject or if the root of the problem
the bug reporter had was that the device wasn't unmounted before
ejection.

> 
> 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.

Ok I'll read your other post. As I understand it what bother you are the
terms, which you fine misleading for non technical users? Something like
“disconnect” might be better but it may be a bit to “physical”.
Basically it should say “do what I want” but it's a bit obscure ;p

I still think umounting and removing/ejecting the devices are two
different operations which should be available to the users. When there
are multiple partitions on a key or on a hard drive, it's convenient to
be able to umount one without removing everything. Same goes for
encrypted partitions.

The current way we do things are a bit unconsistent, but it's a
difficult UI problem I think.

Cheers,
-- 
Yves-Alexis