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

  :device-detection-time
  :device-media-detection-time

see

 http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:device-detection-time
 http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:device-media-detection-time

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.