Nicer way to unmount automatically mounted drives

We could have a daemon in the user's session (not a root daemon), that polls for
open file descriptors on filesystems on devices in mtab. If all fd's are
closed, then umount it. Though, it may just be better to mount removeable
device with the sync option. Yes, writes will take longer. However it gives
the user the interface they naturally gravitate toward (removing a device is
simply removing the device).

Though no way to remove CD devices still.

There was a patch flying around to get hal to handle eject button presses, let
me look for it.

The same issue affects many devices which don't have an eject button, so the
solution must be general enough to handle those cases as well.

Even if the sync option is used, the device needs to be unmounted _eventually_.
 With FAT filesystems, I think it's pretty safe for the unmount to happen after
the device is physically removed, but this is unlikely to hold true for all
filesystems.

I like the idea of the device being umounted when the last Nautilus window is
closed, except that I don't think there's currently any way to get it mounted
again other than reinserting it.

Please note that my last gnome-vfs2 changes cause automatically mounted devices
to appear in the Computer window, where they can be unmounted by right click ->
unmount.

So at least there now is a safe method of unmounting, however, I agree that an
automatic unmounting would be preferable.

By the way, pmount already applies the sync option.

It's not a discoverable way though. Most people never think to try the right
mouse button, it's a silly place to hide it. And Macs don't HAVE right mouse
buttons! What do our Mac users do?!

Being able to eject your CD is a pretty major requirement, and so far we haven't
(imo) created an obvious way for this to happen.

(and is anyone else thinking eww at the new Bugzilla bottom bar colour?

We discussed this some during the Ubuntu meeting today. The original GNOME
setup was to create icons for volumes on the desktop, which at least gave the
user an obvious place to right-click, but we've removed those icons.

We discussed the idea of attempting an auto-unmount under certain circumstances:

- when the last nautilus window is closed
- when no process is using the volume anymore
- after the device is unplugged (! this actually seems to work OK with a
sync-mounted FAT filesystem)

Regarding unmounts after the fact, Thom pointed out that hal apparently already
does this:

<thom> 19:12 < sjoerd_> thom: hal runts lazy umount if a device is gone

The code seems to be in hald/linux/block_class_device.c:force_unmount. Perhaps
this just needs to be tweaked to run pumount, and things will work quite nicely
for FAT filesystems.

(In reply to comment #8)
> Regarding unmounts after the fact, Thom pointed out that hal apparently already
> does this:
>
> <thom> 19:12 < sjoerd_> thom: hal runts lazy umount if a device is gone
>
> The code seems to be in hald/linux/block_class_device.c:force_unmount. Perhaps
> this just needs to be tweaked to run pumount, and things will work quite nicely
> for FAT filesystems.

I'm working on an updated hal for this currently.

Lazy unmount should cover the common case; what's the status of that?

(In reply to comment #10)
> Lazy unmount should cover the common case; what's the status of that?

It doesn't appear to be possible to get the information from hal to enable g-v-m
to pumount the device. Sending the callback as early as possible still results
in g-v-m not getting a response from hal with the necessary information until
long after the device is deleted from hal's database.

 hal (0.2.92-1ubuntu9) warty; urgency=low
 .
   * Use pumount to unmount devices on removal.

(In reply to comment #10)
> Lazy unmount should cover the common case; what's the status of that?

I just uploaded a new pmount package which, together with Thom's new hal,
unmounts ripped off USB/FireWire devices. As long as no process wants to write
to the device any more, this is now actually quite safe. However, I'm apt to
reopening this bug since I still think that a desktop icon or a panel applet
would be better and more consistent.

Yes, we should revisit this for Hoary, perhaps reopen and downgrade to enhancement

This is still a problem for CD-ROMs which are automounted, which the user wants
to eject or burn

I'm not sure whether it is a good idea to let me learn gnome programming and
write such a panel applet during the freeze. It will probably take me much
longer than an experienced gnome freak and will probably get much buggier. But
even a gnome freak certainly has to introduce a lot of new code, which is
against the idea of a freeze.

Does anybody see an easy and unintrusive solution for this? Or should we just
reenable the desktop icons for Warty?

I'm not sure this is important enough for WartyWarthog, given that you can
unmount by context-clicking in the Disks (computer://) folder. We can always
document that and leave it to HoaryHedgehog, unless anyone can suggest a reason
why we can't go without (which would have to be pretty major, given the
schedule). Setting milestone.

What Nathaniel mentioned in comment 3, namely listening for eject button presses
and acting on that, is that doable? If so, that's surely the right thing to do.
That's how my mother would expect to eject an inserted CD. She would have zero
chance of figuring out the right-click thing in Computer->Disks; heck, she would
probably not figure it out even if a CD icon was on the desktop, simply because
right-clicking is involved.

(In reply to comment #18)
> What Nathaniel mentioned in comment 3, namely listening for eject button presses
> and acting on that, is that doable?

Until now I did not find out how to detect that. No kernel message, no hal
event, no nothing. I don't know about the internals of CD-ROM drives, but if
they are locked, do they actually report eject button presses?

(In reply to comment #19)
> Until now I did not find out how to detect that. No kernel message, no hal
> event, no nothing. I don't know about the internals of CD-ROM drives, but if
> they are locked, do they actually report eject button presses?

There was a patch for hal for this (I believe). Though, it was rejected and/or
removed for some other reason I don't remember. This is probably a Hoary issue,
but the cdrom eject button *needs* to eject the cdrom. Anything else is
attrocious UI.

Mark, we need some discoverable way for the user to unmount devices which have
been automatically mounted. The interface provided by upstream is the volume
icons on the desktop, which we have disabled. How would you feel about
re-enabling them as a quick and bug-free fix?

I think this is important for WartyWarthog.

- User inserts CD
- CD is automounted and window pops up
- User has no idea how to get CD out of the drive

WartyWarthog users who are not already experienced with GNOME won't even go
looking for the Computer folder

*** Bug 8311 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> (In reply to comment #19)
> > Until now I did not find out how to detect that. No kernel message, no hal
> > event, no nothing. I don't know about the internals of CD-ROM drives, but if
> > they are locked, do they actually report eject button presses?
>
> There was a patch for hal for this (I believe). Though, it was rejected and/or
> removed for some other reason I don't remember. This is probably a Hoary issue,
> but the cdrom eject button *needs* to eject the cdrom. Anything else is
> attrocious UI.

A relevant thread is
http://freedesktop.org/pipermail/hal/2004-May/000238.html

The Warty version of hal still contains the code which should check for eject
buttons: http://freedesktop.org/pipermail/hal-commit/2004-June/000109.html
but it does not work at least on my system. Also, the code is not present any
more in the current upstream version 0.2.98. I will ask David (upstream) about that.

Since the recent gnome-vfs2 now shows icons on the desktop, I think we can set
the milestone to Hoary now?

Since James currently works on the implementation, he agreed to assign this bug
to him.

I started working on a rewrite of the old drive mount applet that should fill
this need, as Martin mentioned. The Gnome bugzilla bug report is here:
    http://bugzilla.gnome.org/show_bug.cgi?id=155188

A snapshot of my code (not in applet form just yet -- it just runs in a separate
window) is here:
    http://www.gnome.org/~jamesh/drivemount-new-20041014.tar.gz

Ideally, I'd like to have zero preferences for the applet. To do this, I made a
few changes compared to the old applet:

- display buttons for all drives in one instance of the applet, instead of one
drive per applet instance. Automatically add/remove buttons as volumes are
plugged/unplugged.
- Use gnome-vfs's GnomeVFSVolumeMonitor to list drives, monitor drive state and
handle mounting/unmounting. This also means that Nautilus will drop dnotify
watches when we want to unmount a volume (so it can actually be unmounted), and
also close all associated windows.
- Use the same heuristic as Nautilus in deciding whether to eject on unmount: if
it is a cdrom, zip or jaz drive, eject the disc.
- Ask gnome-vfs what icon name to use for a particular drive and grab that image
from the icon theme.

Once this is finished, it might fit nicely at the left end of the bottom panel.

Do you have code that we can push into Hoary and start testing?

The code is merged into the gnome-applets package now, so will be in Gnome 2.10.
 Would it be helpful if I backported it to the 2.8 branch during testing?

Since this applet is an upgrade of the existing drive mount applet (it uses the
same applet ID so that upgrades work right), having a separate package is
probably not that easy -- it would either conflict with gnome-applets-2.8.x
(same applet ID), or use a different applet ID which would make upgrades to 2.10
a problem.

That's Sebastien's decision; however he would prefer to bring it into Ubuntu is
fine with me.

GNOME 2.9.1 is due next week and will go in hoary so we will just wait some days
for it :)

the applet is in hoary, should we close this bug now ?

works for me

THis has been fixed for a while, closing.