[Nautilus-list] File manager integration with magicdev

[Owen Taylor <otaylor redhat com>]

Since there seems to be considerable discussion and wheel-reinventing
currently going on about the interaction of the file manager with
automounting and devices, I thought I should briefly review how
GMC interacts with the magicdev automounter. 

Some of this discussion is Red Hat specific, but I think the general
approaches are sane, and can form the basis of broader solutions.


For background, magicdev works by:

 1) Monitoring whether there is media in the drive

 2) If it detects that media has been inserted, it checks the type
    of the disk, and either:

    - Mounts the CD if it is a data CD
    - Runs a user-specificied command if it is an audio CD (defaults
      to gtcd)

 3) When it detects that a data CD has been mounted it:

    - If the CD has a autorun file, presents the user with the option of 
      running it.
    - Opens a new file manager window for the CD

Also, (and importantly for this discussion), when it detects a change
in state for a device, or a change in the list of mountable devices in
the fstab, after performing its actions, it notifies the file manager
via CORBA that it should refresh its list of devices.

    
All of these actions (automounting, CD playing, opening file manager windows
are disableable from a control center capplet)

Magicdev exports a CORBA interface:

===
module GNOME {
  interface MagicDev {
    void reread_config();
    boolean is_running();
  };
};
===

That is used for two things:

 - By MC to check if an automounter is running (the behavior is slighly 
   modified in this case.)

 - To ensure proper notification of config changes (one of the few programs
   that got this right in the benighted pre-GConf days.)


Also, in recent Red Hat (current beta versions), there is additional
interaction of this with the support for hot-plug devices - hot-plugged
devices are automatically added to fstab so that magicdev notices
them and notifies GMC to refresh the desktop.

The IDL that MC exports is quite simple - you can find it at:

 http://www.gnome.org/lxr/source/mc/idl/FileManager.idl

One the MC side of things, MC keeps track of potentially mountable
devices in a similar way to magicdev - by reading fstab and
mtab. However, instead of continually polling, refreshes are triggered
manually by the user from the root desktop menu, or from magicdev via
CORBA.


Some notes about the intepretation of fstab and mtab:

 - Potentially magicdev-mountable devices CDROM drives (and similar
   devices that are classed as CDROM drives) with the 'user' or
   'owner' flag in fstab.  'user' means that anyone can mount the
   device. 'owner' means that the owner can mount the device, and is
   used in conjunction with Red Hat's PAM/usermode facilities for
   changing ownership to the currently logged in user.

 - If an automounter is running, GMC only displays magicdev-mountable
   devices when they are actually mounted.

 - The way GMC (or at least, the current Red Hat packages) name devices
   is dependent on another fstab option 'kudzu'. If this is set, 
   then the device was created as part of the hot-plug support, and
   was created with a meaningful name for the mountpoint. So, GMC  
   uses this name for the file on the desktop.

   It also knows enough about these names to put up appropriate icons
   for zip disks, memsticks, and so forth.

   In other cases, GMC just numbers devices of each type Floppy 1,
   Floppy 2, CD-ROM 1, CD-ROM 2.


I can provide more details, though I would also advise reading the
code:

 The magicdev code is ugly but short. (magicdev/magicmedia.c.)

 The gmc code is very clean, except where I've hacked it up a bit
 recently (mc/gnome/{gmount,gdesktop.c}.) The hot-plug relevant
 changes aren't in CVS. I've put the latest (and not changing) 
 package at:

  http://people.redhat.com/tmp/mc-4.5.51-32.src.rpm

 If anybody wants to take a look.


OK, that's probably vastly more than most people wanted to know. The
summary, though is that:

 - Detecting this stuff is quite system specific, and involves 
   considerable interactions with the automounter.

 - Given that, there is no reason for the file manager to be constantly
   peeking at fstab/mtab.

 - We already have interfaces for file manager / automounter interaction
   and I would recomommend we reuse/adapt them.

Regards,
                                        Owen