Iomega Zip drives are so ubiquitous in the PC hardware universe that I expect to see a report soon that archeologists have discovered an Egyptian tomb with mummified Zip cartridge instructions. It'd probably be in Mac format, though.
Iomega Zip drives are so ubiquitous in the PC hardware universe that I expect to see a report soon that archeologists have discovered an Egyptian tomb with mummified Zip cartridge instructions. It’d probably be in Mac format, though.
The capacity of Zip cartridges and their widespread use makes them the ideal form of “sneakernet” for moving files between systems, including between different computers. While using Zip drives with Linux and most desktop environments isn’t all that difficult, it’s a bit involved, and I’ve come across a few details that I haven’t found documented anywhere else. The online references mentioned in this column are listed in the Siteworthy sidebar.
First, there are three different ways to connect a Zip drive to your computer: SCSI, ATAPI/IDE, and parallel port. The SCSI and IDE variations are pretty straightforward and work just like a hard drive of the same type — you hook the drive up to the interface and then mount, use, and unmount it. The naming convention is the same as that used for all drives attached via IDE or SCSI interfaces. For example, on one of my systems I access Zip cartridges as hdc4, which decodes as IDE drive (hd), third IDE device (c), and the fourth and only partition (4).
Parallel-port Zip drives are slightly more complicated, which is a shame, since being able to move the entire drive between systems can be a great advantage. More than once, I’ve benefited from carrying a parallel-port Zip drive and a couple of empty disks on business trips, allowing me to bring back files without hassling with network connections or splitting files.
This column will discuss the classic 100 MB Zip drive. There is also a 250 MB model, as well as the 100 MB Zip Plus, both of which require different software support. Those use the imm kernel module instead of the more common ppa module. Both imm and ppa are device drivers that know how to communicate with various types of hardware.
To get Linux to talk to a 100 MB parallel-port Zip drive, you’ll need to have the paport and ppa kernel modules. In Red Hat 6.0, these modules are part of the default configuration, so you should be all set. Regardless of your distribution, you can test for the presence of the needed modules by attaching your Zip drive and running either the single command:
or the pair of commands
Try modprobeppa first, and if modprobe isn’t found, or it reports a failure in trying to load ppa, then try the pair of insmod commands. With a stock Red Hat 6.0 installation this works just fine, and you’ll see several messages about what the modules are doing as they attempt to load and then find your Zip drive.
If the modprobe or insmod commands fail outright, then you probably don’t have the needed support installed in the kernel and/or modules, and you’ll have to rebuild your kernel and modules. This may seem like a lot of work just to get a Zip drive to work — compiling your kernel is not to be taken lightly — but the silver lining is that kernel compiling is becoming much easier than it once was. The key configuration details are that you need SCSI support and SCSI disk support in the kernel, and Iomega Zip and printer support built as modules. (This SCSI requirement isn’t surprising, considering that the parallel-port Zip appears as a SCSI device, even on an all-IDE system.) See the Kernel HOWTO and the Zip Drive mini-HOWTO for all the details on how to rebuild and install a kernel with these options enabled.
If your Zip drive is empty, you’ll get some ominous messages that say things like READ CAPACITY failed, scsidisk I/O error, and unable to read partition table, even though everything worked. You can safely ignore these, or mentally translate them to, D’oh! There’s no disk in the drive!
If you know that you’ll always need your parallel-port Zip drive available, you can add the command:
modprobe ppa >& /dev/null
to your logon script (~/.bash_ profile for bash users. This is kept in your home directory). This will run the command, redirecting all those nasty (but pointless) error messages to the bit bucket and away from your screen.
Once you have a disk in the drive and the ppa module successfully loaded, you can mount the drive with the command:
mount -t vfat/dev/sda4/ mnt/zip
This example assumes that the Zip is the first SCSI device in your system (sda), the disk is partition four and formatted for VFAT, and that the directory /mnt/zip exists and is where you want the Zip disk’s contents to appear. As they say on the cooking shows, adjust to taste.
Figure One: KDE Zip drive configuration.
Before I forget, one other quirk of Zip cartridges that trips up a lot of people is partition numbering. For reasons known only to Iomega and the computing gods, all IBM-format Zip cartridges are created with a single partition, numbered four. If this unduly disturbs your sense of order, you can use fdisk to delete the existing partition (and your data!) and create a new one numbered anything from one to four. In my opinion it’s not worth the bother, though. If nothing else, this will cause problems for you when exchanging disks with other Linux users who will expect the odd-but-standard partition number.
Similarly, you can reformat Zip cartridges to use ext2fs, Linux’s preferred filesystem type, but for the most common uses of Zip drives — backups and ultra-low-bandwidth wireless networking — VFAT (the Virtual File Allocation Table filesystem used by Windows 95/98) works fine, and it ensures that you can read the disks from DOS and Windows, if needed.
This is all well and good, but you’d probably like to make Zip drives a lot more usable, particularly in one of the “big two” graphical environments. As it turns out, that’s pretty easy whether you’re using KDE or GNOME.
Once you have your Zip drive attached and accessible (meaning you’ve done the modprobe/ppa thing for parallel-port drives), you can make your drive accessible under KDE. The magic recipe can be seen in Figure One.
1. Create a desktop icon for the Zip drive. Right-click on the desktop and select “New -> File System Device” from the menu that pops up. This opens a dialog box that lets you name the link. Call it Zip.kdelnk, but you can use any valid name for the part before the .kdelnk part.
2. When you close the link-naming dialog box, another, different one automatically opens, this time showing the properties of the link. Set the file permissions and ownership in accordance with your local security policies Also set the device (/dev/sda4 for a parallel-port Zip), the mount point (I use /mnt/zip), and the type of filesystem on the disk. The filesystem selection is a little more involved, as I’ll explain below, but for now you can just leave it as “Default,” which will use the filesystem setting you’ll add to /etc/fstab in the next step. Finally, you can set the icons that you want KDE to use for the Zip when it is and isn’t mounted. (There are a pair of nice Zip icons at the very end of the list that KDE presents.) When you’re done, close this dialog. See Figure One for a sample of how I configured a Zip on my system.
3. To make the Zip drive available automatically when you boot your system, you need to edit /etc/fstab (you must login as root to do this) with any text editor and make sure there’s an entry for your Zip drive. For my parallel-port drive, the line looks like this:
/dev/sda4 /mnt/zip vfat user,noauto 0 0
Remember to use the correct device name (in my example, it’s /dev/sda4), mount point (/mnt/zip), and default filesystem (vfat) for your configuration. Please note that the user token in this line gives non-root users the ability to mount the device, write to it, and run files from it, which might not be in keeping with your local security policies.
To use what you just configured, just pop a VFAT-format disk into the drive, click on the Zip icon on your desktop, and KDE will mount the drive and open the KDE file manager to display the mount directory. You can also right-click on the icon and select menu entries to mount or unmount the drive, as needed.
If you routinely use Zip drives with different filesystems, KDE supports another, very useful option. Right-click on the Zip icon and select “Properties” from the menu to display the configuration dialog. On the “Device” tab you can change the filesystem to include more than one entry, if you separate them with commas. This will result in KDE showing you each different filesystem as a separate entry on the icon’s menu, with names like “Mount ext2″ and “Mount vfat.” This will let you correctly mount the disk according to whatever filesystem it contains, with a single desktop icon. A “default” entry in this field causes KDE to use the filesystem listed with this device in your /etc/fstab file, and it appears as just “Mount” on the menu.
The GNOME support for Zip drives is almost as complete as that provided by KDE, but it’s just a bit quirkier. The user’s guide for GNOME says that “any drives you have connected to your system will be shown on your desktop with the appropriate icons.” GNOME wouldn’t do that automagically for me with a parallel-port Zip drive. After a little fiddling around I found the secret formula.
First, have your .bash_profile and /etc/fstab entry set as described above, so that Linux has the proper support and information ready.
Next, open a command line and go to your GNOME desktop directory, which is /home/<user name>/ .gnome-desktop/ (/root/.gnome-desktop/ for root). Create a symbolic link for the mount directory you want to use for your drive with the command:
ln -s /mnt/zip “Zip drive”
Change the mount point part of this command (/mnt/zip) to reflect whichever mount point you are actually using (this is the place where the filesystem on the Zip cartridge will be grafted into your current filesystem). You can give the symbolic link any name instead of “Zip drive” in my example, but, as always, make sure you place it in quotes if you use a name that contains a blank.
Figure Two: GNOME’s Zip drive configuration dialog.
Now, when you start or return to GNOME, you should see a desktop icon with the name of your symbolic link. If you entered the ln command from an xterm window, you’ll have to tell GNOME to rescan its desktop before your new link and icon will appear. Right-click on the desktop and select the “Rescan desktop” choice.
When you right-click on your Zip-drive icon, you’ll see options to either mount or unmount the drive (Figure Two), depending on its current status, and also an eject entry. If you double-click on the icon with your left mouse button, GNOME will mount the drive, if needed, and open a Midnight Commander window to display the drive’s contents.
The one notable KDE feature that GNOME is missing is its ability to configure one drive for several filesystems. There is a way around this limitation, though. You create several mount-point directories, for example /mnt/zip_ext2, /mnt/zip_vfat, and so on, one for each filesystem you use with Zip cartridges. Then you create a separate desktop link and icon for each with the ln command, as shown above, using a different and appropriate symbolic-link name for each. Finally, make sure your /etc/fstab file has one entry for each different Zip-drive filesystem, but all pointing to the same hardware device. For ext2fs and VFAT filesystems, the lines in my /etc/fstab file look like Listing One.
Listing One: Creating Different Mount Points for Your Zip Drive
Now, you can use the appropriate icon for each filesystem type, and mount, use, unmount, and eject cartridges at will. You could argue endlessly over whether this technique is a neat trick or an unforgivably ugly hack. Given how easily it lets you access different filesystems on Zip cartridges, I’m willing to overlook the extra desktop icon. (I still prefer KDE’s way of handling this, however.) Of course, a simpler method is to just stick with the default VFAT formatting on IBM-style Zip disks unless you have a genuine need to switch to something else.
I guess you could say that Linux likes Zip drives. With just a little effort you can make just about any Linux system, whether it’s your own or that of a co-worker, friend, or relative, work with Zip drives about as conveniently as one could want. In future columns I’ll revisit the topic of device support several times. If there’s a desktop peripheral you’re particularly interested in seeing covered, drop me a line.