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