A different approach…HAL

I use some custom scripts to store data on my ZIP diskettes. I have a dozen of them and when I insert them into the drive they automatically mount. I like this. The problem is that the mount-point gets its name everytime from the diskette’s label, so I have to make my scripts find out which one is mounted and then proceed to the backup. This is useless. And what happens if I change a disk’s label? I would most probably have to modify the scripts too.

UDEV rules can provide a decent solution to this situation by creating a symlink to the ZIP disk’s node, so that it would always be accessible by my scripts. We discussed all this in my previous post. This time I’ll approach the above problem in a different way. If I could make my ZIP disks automount to the same mount-point every time, I wouldn’t have to make any modifications to my scripts. So, how the disks get automatically mounted?

This is when HAL enters the scene… HAL probes our hardware and keeps detailed information about it. Other programs use this information in order to interact with our devices. For example, when I insert a ZIP disk in the drive, HAL probes it and collects info about my disk, its filesystem, volume properties etc. Then gnome-volume-manager, together with fstab-sync, use some of this info to automount the disk using the proper mount options. The same thing happens with all hotpluggable devices like usb sticks, cameras, portable audio players etc.

There is a very handy tool that comes with HAL, the hal-device-manager. Just run in a terminal:

# hal-device-manager

While it is open, if I insert a diskette in the ZIP drive, the volume shows up immediately in the device tree. In the right panel’s advanced view is all the detailed info about it. It consists of the keys, their type and their value. Some keys are just informational, but some others have critical info for the normal interaction between the device and the operating system. Taking a closer look at the properties, I see a key named volume.policy.desired_mount_point. All I need to do is to change this property to a standard value.

In short, this is how it is done. You write down some rules that uniquely identify a device or a partition, and then you change this particular device’s or partition’s properties. These rules are kept in files in /usr/share/hal/fdi/policy/. You should create a directory in there, named 95userpolicy, to save your rule files, so that you do not modify the existing directories and their contents because they might get updated by Red Hat. Just remember to save your rule files with the .fdi extension.

And now, the best part. Rule creation! I would advise you to study the fdi files that lay around in the other directories, just to familiarize yourself with their format. There are some properties enclosed in “match” tags. These contain the properties that HAL tries to match in its metadata. I need to change one of the ZIP diskette’s properties, so I need to tell HAL how to find that volume.

At this point, the HAL documentation and hal-device-manager are your assistants. You can check the keys’ values in hal-device-manager for the device you want HAL to match and find their description in the documentation.

The HAL Specification.

You may also download my fdi file for the ZIP disk:

iomegazip100usb.zip

To distinguish the ZIP disk’s volume from the other devices I created the following four match rules:

key="block.is_volume" bool="true"

The disk has this key set to “true”. From the documentation: True only when the block device is a volume that can be mounted into the file system.

key="volume.fsusage" string="filesystem"

The disk has this key set to “filesystem”. From the documentation: The volume is a mountable filesystem.
So, using these two rules I limit HAL’s search to block devices that are volumes and have a mountable filesystem.

And now two tricky ones:

key="@block.storage_device:storage.vendor" string="IOMEGA"
key="@block.storage_device:storage.model" string="ZIP 100"

In my device tree in hal-device-manager, there is the ZIP 100 device which contains the ZIP disk (the volume). These two have some keys with exactly the same values. One of them is the block.storage_device. So, in order to tell HAL that I exclucively want to change the disk’s properties and not the drive’s, I write a rule that says: From all the devices that have the same value in the block.storage_device key choose the one that has a parent device with a key storage.vendor equal to “IOMEGA“. Moreover, don’t match the block.storage_device key’s value, but match the storage.vendor instead. The same stands for the other rule too, but this time I match the parent device’s model.

With these 4 match rules, we are sure HAL will know that we want to modify the ZIP disk’s properties.

The next step is to change the volume’s properties. I need to change the mount-point to a standard value. This is done by writing the key and its new value enclosed in “merge” tags. I modified:
the “volume.policy.desired_mount_point” key and set it to “zipdisk“.
the “volume.label” key and set to “ZIP Disk 100MB”
The latter change is just for cosmetic purposes.

I save the file, eject and reinsert the ZIP disk into the drive and here it goes: It is automatically mounted in /media/zipdisk, and the desktop icon has the label “ZIP Disk 100MB”. So, from now on all of my ZIP diskettes get automounted to the same mount point regardless of their volume label.

Refer to the HAL documentation for more info. I managed to do these after a lot of trial and error. HAL is something new and the info you can find in the web is very limited.

Related Articles