First of all, let me tell you that I am a fan of the supermount feature that had been floating around a long time but Linus was stupid enough to overlook the potential for benefit to home pc and work pc users. He seems to be more interested in bringing linux all that SMP stuff for extreme-used webservers and other LAN server stuff. Yes, we all can benefit from this as it makes the OS better in lots of ways, but at the same time some of the changes do simply break the supermount feature over and over again. The supermount feature does currently work fine with all devices that can signal their state to the kernel, most prominently the modern ATAPI cdrom device which can tell to the software when the tray opens, so that the kernel can always be sure that the same disk is in there. But for stupid devices like a floppy disk the supermount logic will be broken in every third linux minor version you get - just don't count on it.

Maybe I have to note that even RMS (Richard M. Stallman) has asked on the linux-kernel mailinglist whether linux could be made to support a logic just like windows/msdos had with their drive letters, at least somewhat similar, and everybody pointed to supermount as the name of the feature. However, the supermount logic is not the only answer to the actual problem - all we really want is to insert a cdrom or floppy disk into its drive and then just access it, read it, write it, and take it out again with no mysterious "mount" and "unmount" commands inbetween - or see the cdrom drive locked when forgetting about it.

The other answer to the problem is generally called "automounter" and some kind of automount facilities and automount daemons have a long tradition in unix history - with the bsd automounter having the fame to have been popular for quite a time. The linux kernel does now ship the necessary stuff to setup an automount daemon, and these features work reliably. Furthermore, all linux distributions will ship along the autofs daemon and init.d startup script to start the automounter - and preinstall an /etc/auto.master and /etc/auto.net configuration file. AFAICS, Mandrake is the only distribution to ship a default kernel with supermount, whereas autofs is available in all distributions.

Well, if that would be so easy, there would no need to make up a howto about this feature, you know - the autofs feature is not actually meant for drives with removable media (so is the technical term) but it was meant to automount harddisk on another PC, somewhat like a windows network share in SMB speak, similar to what the samba service can do for you. This automount scheme means that you just need to try to access a /net-path (as specified in /etc/auto.net) and the harddisk partition will be mounted to your local disk tree for just as long as you need it. When there is no activity on the net-volume then the automounter will automatically unmount the network-share again, and usually this is done after a couple of minutes - just compare this with your favourite screensave that blanks your monitor after a few minutes (or even "lock"s the desktop) and so does the automounter daemon - it will "sync" all changed-data back to the net-volume and unmount it, just to be safe since the other PC could possibly get shut down somehow.

However, we can use the automount feature for us and some removable media type drives on the local computer - the trick is that we do not use an umount-timeout of 600 seconds (the internal default of the autofs daemon) and we do not use 60 seconds either (which is the usual default that most init.d/autofs scripts will use or which you will find as "--timeout 60" in the /etc/auto.master file) but we use a much shorter value - something that a common user will not recognize as a timespan or anything the user could get nervous about when waiting. Just choose a timespan between 3 seconds and 6 seconds and it will work. If you are going to install the autofs feature for a user who does not know about mount/umount in the first place, then it is a good idea to use 3 seconds.

That way, you can write some data to the floppy disk, and about three seconds later the computer will actually write the data as the magic "unmount" will have to sync the data back that was just cached before in the PC core. Likewise there is no problem when you just read some data of the cdrom and then quickly try to open the tray with the button on the forefront. It might happen that you see the disk locked in - but the next hit on the button will finally open it and give the CD back to you. Well, unless of course some shell of yours is currently still chewing on the directory of the disk itself. Sometimes you have to look through your "file commanders" and see to get out of the cdrom's directory so that the automounter can do the actual "unmount".

The Installation

On RPM based systems like Mandrake, Red Hat or SuSE installation - if it has not been installed by default - is pretty simple: just install the autofs rpm using any of the package managers. These distributions all ship autofs RPMs with their CDs, no need to go hunting for it on the net. For Mandrake the quickest way to install autofs would be "urpmi autofs" from a command line. And make sure to disable supermount as it might clash with autofs: backup your fstab with "cp /etc/fstab /etc/fstab.supermount" and then issue a "supermount -i disable" which will remove the supermount tags from the current fstab.

To actually set up the data, I do recommend that you do not add the removable-media entries to the /etc/auto.net file - that would be misleading the user. Restrict /etc/auto.net to hold disks shared on other computers or atleast disk partitions being network centric and shared with other computers on your network. Instead, create a new file called /etc/auto.vol since the term "vol" is the traditional unix-centric name of what we are about to do - "vol" is short for "volume" and you might want remind yourself of an analogy of a cd-changer with a dozen disk in the box but just one drive to actually read one cd at a time. Likewise, the access path should start at "/vol" on your local system and the "volumes" under that top-directory should be numbered - usually with a name-prefix telling the type of cd-changer or the computer holding the volumes. A traditional name would say "cd-1" or "pc3-hdd".

In this example, I will use the dos-like names of our removable media called "/vol/a" and "/vol/d" for the floppy and cdrom drive - this is in a way a numbering-scheme starting at "a", passing "d" and "e" and going up to "z". Many linux distributions will start to setup a scheme like "/mnt/floppy" but I guess you are fine with "/vol/a" too, and at the same time this is a traditional unix way. Nice eh! :-)

okay, here is your new /etc/auto.master

# Sample auto.master file
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(8).
## /misc        /etc/auto.misc  --timeout=60
## /net /etc/auto.net   --timeout=60
/vol    /etc/auto.vol   --timeout=3    

Note that I did remove the "sample" /misc and /net mountpoints since my home pc does not have a use for them. To let the timeout be passed right there in the /etc/auto.master happens to be a relativly new feature with linux, many older distributions will require to set a install-variable (e.g. suse 6.x) and in some cases you even have to modify the init.d/autofs file.

Then (mkdir /vol ; chmod 775 /vol) to create the mountpoint on your disk - most linux distribution do not have this old/common directory, they just have "/mnt" which is used for some other taks too (e.g. the installation CDs might get mounted there) and so we do not want to abuse it. Next we create the /etc/auto.vol file.

# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage
a               -fstype=auto,rw,sync,umask=002  :/dev/fd0
d               -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom 

which assumes you already have a symlink /dev/cdrom pointing to your cdrom drive (which might be actually /dev/hdb).

And basically, this is it, now you need to restart the autofs daemon using (/etc/init.d/autofs stop ; /etc/init.d/autofs start) and you can start accessing "/vol/a" and "/vol/d". Well, you could of course make a some new icons on your KDE desktop - just rightlick on the background and click on "new URL", then enter an URL as "file:/vol/a" and choose an icon represting a floppy. The next time that you click on that icon, a file-manager will pop up with "/vol/a" in its view - which is the floppy disk of course.

Doing More With It

This scheme with an icon is however needed for another reason - to guess why, just let your file-commander point to "/vol". So, what do you see. What? Nothing? Well, that's good - as long as there is no mounted volume then there should not be an entry. This is very, very important: about once a day, some cron script will run over your harddisk and look for trash files, and cleaning up other stuff like compressing manual pages and such stuff. Nothing important, but this script will often run the whole file tree and when it comes to a directory like "/vol" it will scan all the subdirectories of it - being possibly removable media which are not there (which would not be that much of a problem - the subdirectory would be empty). But when they are there then it will happily scan your cdrom disk. And that is not what you want, right?

At the same time, this is also a problem for all those point-n-click programs being around. Just try to open an image in "gimp" being on the floppy disk. The gimp's "file open" dialog box will open up and let you choose the file in the file tree, but the "/vol/a" directory does not yet exist and there is now way to just say "/vol/a" to get a list of files. You would have to remember the path and filename on the floppy - which is not quite convenient. But again, there is a way around it: create symlinks. The cron-find daemon above will not walk across symlinks since he knows that a symlink will end at a real file or directory that he will come across at another time too - and it would not be good to scan a directory twice.

On the other hand, a symlink is just some text, so it does not mount the disk unless of course someone is trying to read the symlink in the process of trying to open the thing being at the other end of the symlink. In that moment, the disk gets locked&mounted in the cd drive making the "/vol/a" path to magically appear in that very moment. Just try yourself - insert a floppy, and do (ln -s /vol/a /A) create a symlink for "/vol/a" as the name "/A". Now wait three seconds, so that the floppy gets unmounted. Run (ls /vol) - and see nothing, just an empty directory. Then run (ls /A ; ls /vol) and see the "/vol/a" directory to be there since you accessed it through "/A" in less than three seconds before. This will also work in "open-file" dialog boxes - just use "/A" instead of "/vol/a".

Well, you may have guessed now why we called it "/vol/a". If you go and install "cygwin" or some other unix-emulation under windows, then this unix-layer will map the local "A:" to "Z:" drives as direct unix-tree paths calling them "/A" to "/Z". We simply adopted this naming scheme for a true unix system to access the floppy that our windows would call "A:". I expect most users to be able to remember this mapping as "/A". Right? :-)

But we can go even beyond that (which I actually do on my system) and map the msdos/windows drives too. Well, this assumes that your linux installation has detected the win98 partitions on your harddisk and has put them into your /etc/fstab. In many cases, these disk partitions are mounted permanently to the effect that the cron-find scripts will search these drives too while running once a day. Well, this is unnecessary, so let's remove the corresponding lines from /etc/fstab and add them instead to /etc/auto.vol .. including setting up symlinks for easy access.

Even more, I use some of my harddisk as a backup storage and as a backside storage so I can put the mandrake rpms (or the complete cooker rpms) on that extra partition. And since it is accessed through an autofs point, it will not be searched by the cron-find daemon nor will I be able to wrongly delete some stuff there by mistake - it is another partition anyway. To get yet another benefit, just remember those startup times when the screen says "mounted too many times, check forced" and runs "fsck" on your "fstab"-partitions. The "auto.vol" partitions however are not listed in "fstab", so that "fsck" would have to be run manually .. once a year. Since it is just some backup storage, this is not a problem anyway - I do not run programs on those partitions.

After all my, /etc/auto.vol looks like this last table: