Checking volumes and storage devices for fstab entries

David Zeuthen david at fubar.dk
Mon Dec 18 20:24:50 PST 2006


On Sun, 2006-12-17 at 12:51 +0100, Martin Pitt wrote:
> Hi David,
> 
> David Zeuthen [2006-12-14 23:52 -0500]:
> >  - gnome-mount has the same code (copy-paste :-( ..) and if it sees the
> >    device is in /etc/fstab it uses e.g. "mount /dev/sda" to attempt to
> >    mount
> 
> This is one case of what I had in mind with 'might be useful for other
> applications'. If we can rely on hal about having current fstab
> information, those recurring pieces of code for checking fstab could
> disappear (see my other reply for a proposal how to keep fstab info
> current).

So I think the approach I've been trying to advocate is that all
mounting from the GNOME desktop should use gnome-mount such that all
settings are stored in a central location, e.g. in gconf.

In particular, the current VFS layer in GNOME (which is not widely used)
uses this and I expect alexl's new shiny VFS stuff (which is slated to
be widely used) will use the same mechanism and applications in the
future should use this layer to mount/unmount stuff.

> > Also note that gnome-vfs2 might need some fixing since I'm not sure it 
> > works totally reliable for devices listed in /etc/fstab. The problem is 
> > that right now gnome-vfs2 keeps a Volume icon for a /etc/fstab volume 
> > even though there is no device to back it. That should probably be 
> > changed as it simply don't make sense from an usability point of view... 
> 
> Hm, not sure what you mean: if I have a bogus entry in fstab, I don't
> get an icon for this. But I might not have tried hard enough, or with
> my current FDIs just hide that bug.

I'll try to look at this before the GNOME freeze cf. 

 http://live.gnome.org/TwoPointSeventeen

> > Your idea sounds nice I think; it provides admins and users with an easy 
> > way to provide system-wide managed options for storage devices. E.g. if 
> > I'm an admin I can simply add a line to /etc/fstab and then only those 
> > options will be used.
> 
> Heh, back to good ol' fstab configuration :)

Well, yea.. sorta... as a compromise.

> So, it seems that you generally like the idea? How about I clean up
> the current code, think about how to sensibly combine an addon (for
> inotify'ing) with a probe (for supporting hotpluggable file systems)
> to keep fstab information on hal device nodes current and report back
> again?

I'd really like to avoid this as it's slighty more complicated and
introduces new properties we'd have to maintain. Plus, applications
won't need this.. upon o.fd.Hal.Volume.PermissionDeniedEtcFstab they
just call 

 Mount(mount_point="", fs_type="", options="")

on HAL and since we respect system-wide policy, e.g. /etc/fstab, then
Mount() will use these + uid=<calling-user> and ignore the mount_point,
fstype and options parameters passed.

     David




More information about the hal mailing list