Automatic mounting interferes with {CD-,DVD{+,-}}RW writing

[Matt Zimmerman]

As discussed on the sounder list, it is very confusing when trying to write CDs
to have them automatically mounted. nautilus-cd-burner displays an error, and
the user must figure out how to unmount the disc before they can continue
(Bug#7739). Also, the disc is automatically mounted in the middle of the writing
process, which is even more confusing.

Some ideas:

- nautilus-cd-burner could try to unmount the disc using pumount before giving up

- nautilus-cd-burner could inhibit the automatic mounting mechanism while it is
running

[Nathaniel McCallum (nmccallum)]

Martin: should pmount have a per device lock file? ie. it won't mount if the
device lock file exists.

[Matt Zimmerman (mdz)]

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

[Martin Pitt (pitti)]

I also encountered this bug when trying to write the latest Warty CD.

A solution that really fits into the architecture would be to implement this in
gnome-vfs2. However, since gvm bypasses gnome-vfs and directly listens to hal,
we probably need to talk nautilus-cd-burner (:= ncb) either directly to pmount,
or to gvm; I prefer the latter option since it is cleaner wrt the system
architecture, but this option requires more code, of course. gvm then should
lock the device.

Either way, pmount needs to provide the backend for this. I propose a pair of
new command line switches:

--lock-mount <dev>: umount the device (if mounted) and make future calls to
pmount <dev> fail

--unlock-mount <dev>: enable pmount <dev> again (but do not mount it)

I'm not sure whether it makes sense to implement the complementary --lock-umount
and --unlock-umount as well.

These functions can be implemented with lock files /var/lock/pmount/lock-<dev>,
but pmount should provide a clean interface to this.

ncb would then call pmount --lock-mount at the start of burning and
--unlock-mount at the end. The only problem with this approach is that the
device cannot be mounted any more if ncb crashes in the middle of a burn
process. The next boot will clean /var/lock (AFAIK), but there maybe should be
another fallback. E. .g ncb could intercept some signals.

Comments?

[Martin Pitt (pitti)]

(In reply to comment #3)

Gosh, I stayed up waaay to long last night...

> However, since gvm bypasses gnome-vfs and directly listens to hal,
> we probably need to talk nautilus-cd-burner (:= ncb) either directly to pmount,

That should read "ncb needs to talk either directly to pmount..."

> The only problem with this approach is that the
> device cannot be mounted any more if ncb crashes in the middle of a burn
> process.

Nathaniel, hal should send a message if a device or a CD is removed; we are
already using that for lazily pumounting the device. In this step we could also
unlock the device if it's still locked, this would make the locking system more
robust against ncb crashes.

[Nathaniel McCallum (nmccallum)]

(In reply to comment #4)
> > The only problem with this approach is that the
> > device cannot be mounted any more if ncb crashes in the middle of a burn
> > process.
>
> Nathaniel, hal should send a message if a device or a CD is removed; we are
> already using that for lazily pumounting the device. In this step we could also
> unlock the device if it's still locked, this would make the locking system more
> robust against ncb crashes.

Could we simply add the pid of the process creating the lock into the lock file?
 Then when pmount runs, if a lock file exists and if it contains a pid and that
pid is dead, then clear the lockfile. If the lockfile exists, but does not
contain a pid, keep the lock. If the lockfile exists and contains a pid, but
the pid is alive, keep the lock.

So it would look like this:
pmount --lock-mount <pid (optional)>
pmount --unlock-mount

That is a lot simpler and safer than munging around in ncb :). What do you think?

Nathaniel

[Martin Pitt (pitti)]

(In reply to comment #5)
> Could we simply add the pid of the process creating the lock into the lock file?
> Then when pmount runs, if a lock file exists and if it contains a pid and that
> pid is dead, then clear the lockfile.

Indeed, this is an even better idea.

> So it would look like this:
> pmount --lock-mount <pid (optional)>

Hmm, I wonder if the explicit pid parameter is really necessary. Maybe getppid()
is enough for this? Well, I'll think about this.

[Matt Zimmerman (mdz)]

The pid parameter should be explicit; consider for example a situation where a
program calls an external script to do the mount, but the pid of the program
itself should be monitored for locking purposes

[Martin Pitt (pitti)]

Okay, but then we need to have unlock take a pid parameter as well, because
there might be two or more programs in parallel which want to lock a given
device. pmount would then only mount a device if no (valid) locks are on it any
more.

[Matt Zimmerman (mdz)]

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

[Martin Pitt (pitti)]

I worked a bit on pmount to support locking now. I put the source package, a
i386 deb, and a diff from version 0.1-2 on
  http://www.piware.de/pmount/

The diff is pretty large, but most of the changes involve only moving of code.
The code is now much more robust and easy to read. If I had left the code as in
0.1, the locking features would have needed even more code replication and the
command line parsing would have been even scarier.

If we had this, we could fix nautilus-cd-burner quite easily. But since the
pmount changes are quite large, the code should be at least reviewed by one or
two other people (I took my best to make it rock solid, but Murphy is always
present). If that is too much for Warty, I will accept this as well, but then we
need a different solution. Any ideas?

[Martin Pitt (pitti)]

I just saw that the diff tp 0.2 is pretty useless; e. g. it did not properly
diff the main() method, but diffed the former main() against the new
make_mountpoint_name() and showed main() as completely new.

So I guess it's better to directly read the code. You can also look at the
individual arch commits in

sftp://<email address hidden><email address hidden>

[Matt Zimmerman (mdz)]

As discussed at the tech board meeting, Sebastien will look into this and talk
to nautilus-cd-burner upstream about the most appropriate solution

[Martin Pitt (pitti)]

Sebastien and I talked about this today. He talked with upstream and asked me to
take this back, since his bug list is waaaay longer than mine :-)

Basically we have two options here:

1. upgrade to new hal, dbus-1, gnome-volume-manager, and nautilus-cd-burner
packages, which should handle locking upstream
2. Use the new pmount 0.2 (http://www.piware.de/pmount) which provides locking
and fix the current nautilus-cd-burner to use it

Both options involve new upstream code. 1. involves much more code, thus is more
likely to break existing functionality; 2. involves relatively little new code,
but this code runs partly as root, thus has higher security threats.

pmount implements crash-robust locking, but is a custom solution; 1. will keep
the drive locked if n-c-b crashes, but is upstream.

Here we have the options. Which one shall we go for?

(My personal preference: 2 for Warty, 1 for Hoary)

[Matt Zimmerman (mdz)]

In the medium- and long-term, new code from upstream is less of a maintenance
problem than new code which is specific to Ubuntu, so I would prefer to take the
new GNOME/freedesktop stuff if possible.

gnome-volume-manager and nautilus-cd-burner already have blanket exceptions due
to being part of GNOME. If you and Nathaniel can do some intensive hal/dbus
testing, and provide packages for the community to test as well, to provide some
assurance that there are no serious regressions, I am willing to take the new
upstream versions.

[Martin Pitt (pitti)]

Okay, I will start to package and test new hal and dbus packages tomorrow, and
put them to a public place for other people to test. I hope that hal behaves
sanely (0.2.97 did not work at all for me).

[Martin Pitt (pitti)]

Created an attachment (id=215)
Proposed patch for unmounting the CD before burning on it

This patch goes together with a new upstream version which supports locking.

[Nathaniel McCallum (nmccallum)]

looks good

[Matt Zimmerman (mdz)]

The latest packages here:

   deb http://people.no-name-yet.com/~pitti/utopia/ /

work perfectly for me. I loaded everything up, inserted a CD-RW (which was
mounted and browsed), wrote a new image to it (which unmounted the device, and
didn't touch it again during the burn), then ejected it and reinserted it, and
it was mounted and browsed again. Great work!

[Matt Zimmerman (mdz)]

There do seem to be some problems with the upgrade; I saw gnome-volume-manager
die once, but I think it was the same old Bug #8307. I tested other pluggable
devices and the packages seem to be working quite well. This was the first time
I had experimented with the lazy unmounting; it works perfectly for me.

Have there been any problem reports about the new packages?

[Martin Pitt (pitti)]

Fixed in:
nautilus-cd-burner (2.8.3-0ubuntu2) warty; urgency=low

  * debian/patches/cdrom-umount.patch: updated to unmount the volume, not the
    drive; this caused a segfault on some machines, which does not occur with
    this version of the patch

 -- Martin Pitt <email address hidden> Tue, 28 Sep 2004 11:19:23 +0200

nautilus-cd-burner (2.8.3-0ubuntu1) warty; urgency=low

  * New upstream release: now supports drive locking (Warty bug #7992)
  * debian/patches/cdrom-umount.patch:
    - try to unmount a mounted CD-RW before attempting to burn it (also Warty
      bug #7992)
    - requires build-dependency libgnomevfs2-dev
  * raised build-dependency of libhal-dev to >= 0.2.98 to ensure locking
    support

 -- Martin Pitt <email address hidden> Mon, 27 Sep 2004 18:07:43 +0200

(together with the new hal 0.2.98 and gnome-volume-manager)

[Matt Zimmerman (mdz)]

I'm getting this behaviour again with current hoary; was this patch lost?

[Matt Zimmerman (mdz)]

Still here...

[Sebastien Bacher (seb128)]

ok, the bug got dropped because the feature is in the upstream code:

2.8.4:
Try to umount the CD in the drive if it's busy

I've just tried here, it works fine.

Perhaps there is something useful in the debug log. To get it:
- unset /apps/nautilus/preferences/show_desktop in gconf-editor
- set /apps/nautilus-cd-burner/debug in gconf-editor
- run nautilus from a gt -> you'll get the log here
- try to write the CD

[Sebastien Bacher (seb128)]

should be fixed in this upload:

 nautilus-cd-burner (2.8.6-2ubuntu1) hoary; urgency=low
 .
   * debian/control.in:
     - Build-Depends on libnautilus-extension-dev.
 .

nautilus-cd-burner (2.8.6-2) unstable; urgency=low
 .
   * debian/control.in:
     - Build-Depends on libhal-dev (>= 0.2.98).
     - updated the libnautilus-burn-dev Depends.
   * debian/patches/01_amd64.patch:
     - patch from Andreas Jochens <email address hidden> to fix the build on amd64
       with gcc-3.4 (Closes: #287748).
   * debian/patches/02_pmount.patch:
     - add pumount to the list of known commands, should fix the bug with
       busy drives.