fstab-sync

[Ray Strode]

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.

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

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

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

> 4. Mounting from the program doesn't seem very useful; as hald runs as
> root it means that the desktop session won't have write privileges and
> you need to drop to a root shell to unmount the volume.
Yea, quite true.

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

--Ray

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