This is not really a DeviceKit-disks bug, it's a gvfs bug. Anyway, let me try and explain how this is supposed to work since this information applies to any environment attempting to enforce policy. When I've done that, I'll address your bug report and then I'll move the bug to the GNOME bugzilla.
First of all, automounting (and, for that matter, also: autoassemby of RAID arrays, auto unlocking LUKS devices, autoassembly of LVM logical volumes, establishing connections to preconfigured iSCSI connections) is a really tricky business (we don't yet handle LVM or iSCSI but that is on the road map).
This is especially true if you want the added geek-comfort of things working perfectly with the classic command line tools such as fdisk(8), parted(8), mkfs(8), mdadm(8) and so on. And, in GNOME at least, we do want that level of geek-comfort.
For example, if you use the low-level tools from gnome-terminal within a GNOME desktop session, we want the following user experience
1. The desktop shell (e.g. file manager, Places menu in panel, Disk
Mounter applet, file chooser dialogs) should always reflect the current
state of affairs - for example, if you add/remove partitions with fdisk(8)
or parted(8) then you want the desktop shell bits to be instantly updated.
Ditto if you create file systems. Ditto if you create a new RAID device.
and so on.
The way we implement (most of) 1. is through having udev listen on changes on block devices with inotify. E.g. every time the last opener of a O_RDRW file descriptor for a block device closes his fd, then udev will synthesize a 'change' uevent.
Now, this 'change' event bubbles through the udev stack, triggers file system probing (60-persistent-storage-rules.udev), and then gets delivered to devkit-disks-daemon which acts on it (typically turning it into one or more D-Bus signals).
Eventually, the event from devkit-disks daemon reaches the GIO volume monitor implemetation (gvfs-gdu-volume-monitor) in your desktop session and it is turned into appropriate signals on GVolumeMonitor and GDrive/GVolume/GMount objects.
Finally, the desktop automounter (and, in the future, autoassembler) that (currently) resides in the Nautilus process acts on these events.
2. We _only_ want the desktop automounter (and, in the future,
autoassembler) to take action if a couple of conditions are true,
typically if it looks like you've just inserted the device (for example
a USB enclosure with non-removable media) or just inserted the media
for which the block device in question in residing on (for example if
you just inserted a CF card into a USB card reader).
For example, if you create a new partition with fdisk(8) things might
just happen to be in a state (depending on the phase of the moon) so
the newly created partition is picked up (by fs probers invoked by udev)
as a mountable file system. This is typically due to fdisk(8) not clearing
filesystem signatures on the partition. FWIW, This happens more
frequently than you'd expect since many users use same/similar sizes
when repartioning media.
(Of course, if you create partitions/filesystems via the
devkit-disks-daemon interfaces we do clear filesystem signatures so
this can't happen. But we want the old tools to keep working and it
would be wrong for fdisk(8) to start messing around with your data.)
Also, even if you create a filesystem via mkfs(8) then you don't want
it to be automounted.
The way we currently deal with this is by having devkit-disks-daemon export two properties
Having these properties around allows the desktop automounter/autoassembler to make informed decisions. In particular, the GIO volume monitor implementation (gvfs-gdu-volume-monitor) will set g_volume_should_automount() to either TRUE or FALSE, see
based on whether these values are (something like) five seconds from the current time.
Note that the way things work, we will automatically attempt to automount (and in the future autoassemble as well) all user-visible partitions (this includes system-internal partitions) when the GNOME desktop session starts. This is intended. And yes, it would be a bug (and, yes, as your report indicates) if we started popping up dialogs / error dialogs (either via GMountOperation or PolicyKit) if one or more of these operations fail.
Hope this clarifies how things are supposed to work - hope it's not too confusing.
Hi,
This is not really a DeviceKit-disks bug, it's a gvfs bug. Anyway, let me try and explain how this is supposed to work since this information applies to any environment attempting to enforce policy. When I've done that, I'll address your bug report and then I'll move the bug to the GNOME bugzilla.
First of all, automounting (and, for that matter, also: autoassemby of RAID arrays, auto unlocking LUKS devices, autoassembly of LVM logical volumes, establishing connections to preconfigured iSCSI connections) is a really tricky business (we don't yet handle LVM or iSCSI but that is on the road map).
This is especially true if you want the added geek-comfort of things working perfectly with the classic command line tools such as fdisk(8), parted(8), mkfs(8), mdadm(8) and so on. And, in GNOME at least, we do want that level of geek-comfort.
For example, if you use the low-level tools from gnome-terminal within a GNOME desktop session, we want the following user experience
1. The desktop shell (e.g. file manager, Places menu in panel, Disk
Mounter applet, file chooser dialogs) should always reflect the current
state of affairs - for example, if you add/remove partitions with fdisk(8)
or parted(8) then you want the desktop shell bits to be instantly updated.
Ditto if you create file systems. Ditto if you create a new RAID device.
and so on.
The way we implement (most of) 1. is through having udev listen on changes on block devices with inotify. E.g. every time the last opener of a O_RDRW file descriptor for a block device closes his fd, then udev will synthesize a 'change' uevent.
Now, this 'change' event bubbles through the udev stack, triggers file system probing (60-persistent- storage- rules.udev) , and then gets delivered to devkit-disks-daemon which acts on it (typically turning it into one or more D-Bus signals).
Eventually, the event from devkit-disks daemon reaches the GIO volume monitor implemetation (gvfs-gdu- volume- monitor) in your desktop session and it is turned into appropriate signals on GVolumeMonitor and GDrive/ GVolume/ GMount objects.
Finally, the desktop automounter (and, in the future, autoassembler) that (currently) resides in the Nautilus process acts on these events.
2. We _only_ want the desktop automounter (and, in the future,
autoassembler) to take action if a couple of conditions are true,
typically if it looks like you've just inserted the device (for example
a USB enclosure with non-removable media) or just inserted the media
for which the block device in question in residing on (for example if
you just inserted a CF card into a USB card reader).
For example, if you create a new partition with fdisk(8) things might
just happen to be in a state (depending on the phase of the moon) so
the newly created partition is picked up (by fs probers invoked by udev)
as a mountable file system. This is typically due to fdisk(8) not clearing
filesystem signatures on the partition. FWIW, This happens more
frequently than you'd expect since many users use same/similar sizes
when repartioning media.
(Of course, if you create partitions/ filesystems via the disks-daemon interfaces we do clear filesystem signatures so
devkit-
this can't happen. But we want the old tools to keep working and it
would be wrong for fdisk(8) to start messing around with your data.)
Also, even if you create a filesystem via mkfs(8) then you don't want
it to be automounted.
The way we currently deal with this is by having devkit-disks-daemon export two properties
:device- detection- time media-detection -time
:device-
see
http:// hal.freedesktop .org/docs/ DeviceKit- disks/Device. html#Device: device- detection- time hal.freedesktop .org/docs/ DeviceKit- disks/Device. html#Device: device- media-detection -time
http://
Having these properties around allows the desktop automounter/ autoassembler to make informed decisions. In particular, the GIO volume monitor implementation (gvfs-gdu- volume- monitor) will set g_volume_ should_ automount( ) to either TRUE or FALSE, see
http:// library. gnome.org/ devel/gio/ unstable/ GVolume. html#g- volume- should- automount
based on whether these values are (something like) five seconds from the current time.
Note that the way things work, we will automatically attempt to automount (and in the future autoassemble as well) all user-visible partitions (this includes system-internal partitions) when the GNOME desktop session starts. This is intended. And yes, it would be a bug (and, yes, as your report indicates) if we started popping up dialogs / error dialogs (either via GMountOperation or PolicyKit) if one or more of these operations fail.
Hope this clarifies how things are supposed to work - hope it's not too confusing.