Probably the descriptions are a little obsolete, or otherwise gloss over the technical details the end users wont understand.
nautilus has never managed the automounts afaik, the automount helpers (i.e the auto-run actions) did live in nautilus in GNOME2, moved to gnome-settings-daemon in 3.0 and these days live within gnome-shell (Since 3.12 or something). My best guess (and its only that causesince I could never reliably reproduce this bug and poke around with gdb), is that somehow a stale volume ends up stored (possibly due to unclean ejection of cd or just a plain leak) within the volume monitor, there is an update_mounts function in gvfs that is probably triggered by the insertion of the new CD and gvfs/GIO run through this an mount that old leaked volume. Of course it could also be a race or any other number of things, however I don't think its the filemanagers, they are just doing what they are told by the lower level software. I just don't have time to dig into this, especially when I can't reproduce. Now if you were to poke into the GIO volume monitor, you could possibly confirm that, however afaik there is no easy way to do that other than writing code. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1069964 Title: Two processes attempt to mount blank optical discs To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1069964/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
