fstab-sync

[David Zeuthen]

On Thu, 2004-07-15 at 17:14 -0400, Ray Strode wrote:
> Hi,
> > A few observations:
> > 
> > 1. I had to write a small wrapper, see [1], to use it; is this intended?
> > It would be nice if we could just symlink to the installed binary.
> I provided a wrapper called fstab_sync.sh in the callouts directory.
> You just need to copy it to the appropriate place.
> 

Oh, ok, yeah I see, it was just missing from the second patch, although
it was in the former. How about adding support to fstab-sync such that
we don't need that script?

> > 2. The program put /dev/hda1 into my fstab but that one is already there
> > as LABEL=/. This can be resolved by looking at the volume.label for the
> > volume you are processing.
> I'm working on this with John.  We need to figure out what mount does if
> more than one drive has the same label.  

Yep. I suppose the OS installer, Anaconda in the Fedora case, will
create the initial fstab?

> > However, I think that for removable storage without partition tables it
> > makes sense to have the fstab entry anyway; you can check this when
> > processing a hal-device where both block.no_partitions is TRUE and
> > block.is_volume is FALSE. 
> > 
> > This applies to cdrom, floppy, ls120, zip and other funny drives (I
> > haven't tested it on a zipdrive though, haven't got one yet). It would
> > be cool to choose the <name> in /media/<name> after the type or
> > capabilities of the drive; e.g. if I have a CD-ROM and a DVD-RW I would
> > get /media/cdrom and /media/dvdrw. You can use information in the
> > storage.cdrom.* capabilities for this. 
> 
> I currently look at the type of disc in the drive for determining mount
> point.  The idea being that the mount point will be /media/dvd when a
> dvd is put in the drive and /media/cd_rw when a cd-rw is put in the drive.
> The advantage of doing this is in the case of combo drives, the mount point
> will reflect role the drive is currently assuming.
> 
> The heuristics aren't all that advanced yet and could definitely use
> some work.
> 

Yeah. But I suppose that's a regression from the current behaviour of
most Linux distros? It'll probably break existing desktop file managers
(like Konqueror or ROX filer) that is not yet patched to use HAL since
they probably just monitor /etc/fstab and /etc/mtab just like GNOME VFS
does HAL support?

> > Also, check out gnome-vfs-hal-mounts.c in gnome-vfs for how the desktop
> > visible name is computed.
> Thanks for the pointer.
> 

Btw, in the GNOME-VFS stuff I use the displayable name 'CD-RW/DVD-ROM
Drive' for the combo drive in my Powerbook, so perhaps the mount point
could be /media/cdrw_dvdrom?

[snip]
> > 5. The program uses the kudzu option to recognize entries made by the
> > program, perhaps this should be 'hal' instead?
> Actually, it doesn't.  The program assumes that all mounts in the fstab
> listed in /media are auto-generated, unless you define
> USE_NOOP_MOUNT_OPTION (then it uses kudzu).  
> 
> > If think it could be useful to host this program with the hal package 
> > as it's not Fedora specific? If we do this we should probably use the
> > 'hal' option and also host the (trivial) patch to mount that achieves
> > this as well.
> The upstream maintainer of util-linux has agreed to add a "managed"
> mount option, which we can use.
> 

Right.

So I've committed your 2nd patch; much thanks for hacking on this.

Cheers,
David
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal