Reading Foreign File Systems under Linux

Written:
24-Feb-2003

Revised:
02-Mar-2003

Reading Foreign File Systems under Linux
By Thiravudh Khoman

Linux, being the chameleon that it is, has the ability to support many different file systems, either natively or with "outside" help. Besides its native ext2 (and more recently ext3) file system, it can also handle DOS' FAT16 and FAT32, Windows' NTFS4 and NTFS5, OS/2's HPFS, and Macintosh's HFS, just to name a few. Given the recent push to add journaling capabilities, Linux has seen even more file systems being offered closer to home, such as Red Hat's own ext3, Namesys' ReiserFS, IBM's JFS, Silicon Graphics' XFS, etc.

In this article, I'm going to restrict myself to the "foreign" file systems; that is, those that are native to other systems, such as FAT, NTFS, HPFS, and HFS. (Actually, I'm only going to gloss over HPFS.) Hopefully, a future Part II of this article will deal with the new journaling file systems once I learn a bit more about them and actually try them out.

For the record, my "testbed" is a Red Hat Linux v8.0 installation.

DOS FAT16/FAT32 Partitions

Because the pre-Linux world was dominated by DOS/Windows (it still is, of course), support for the two DOS based file systems - FAT16 and FAT32 - were available fairly early. Assuming that your computer has a FAT16 and/or a FAT32 partition available somewhere (either on a single drive alongside the Linux partition or on a separate drive), you can mount these partitions by using the Linux mount commmand.

First, though, you need to find out where the DOS partitions are located. You can do this most easily by issuing the command: fdisk - l. This is what the output of the command looks like for a single hard disk with an NTFS partition, a FAT16 partition, a FAT32 partition, and three Linux partitions (/boot, /, swap):

Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       261   2096451    7  HPFS/NTFS
/dev/hda2           262       392   1052257+   6  FAT16
/dev/hda3           393       523   1052257+   b  Win95 FAT32
/dev/hda4           524      1245   5799465    5  Extended
/dev/hda5           524       536    104391   83  Linux
/dev/hda6           537      1180   5172898+  83  Linux
/dev/hda7          1181      1245    522081   82  Linux swap
total 24

According to this output, the FAT16 partition is located at /dev/hda2, while the FAT32 partition is at /dev/hda3.

The most common method of mounting a FAT16 or FAT32 partition is to issue a command like so:

mount -t fstype device mountpoint where fstype is the file system type (Linux refers to FAT16 as "msdos" and FAT32 as "vfat"), device is the /dev/hda# location of the partition, and mountpoint is where you want the foreign partition to be mounted on your Linux file system . But before you can use the mount points, you have to create them first (if they don't already exist). So, let's do this:

Real life mounting examples would then look like this:

and the files in each partition will show up just below each mount point.

An alternative to manually issuing the mount commands is to add analogous entries into the /etc/fstab file. This will automatically mount the partitions whenever Linux boots up. At present, my /etc/fstab file looks like this:

LABEL=/        /              ext3     defaults        1 1
LABEL=/boot    /boot          ext3     defaults        1 2
none           /dev/pts       devpts   gid=5,mode=620  0 0
none           /proc          proc     defaults        0 0
none           /dev/shm       tmpfs    defaults        0 0
/dev/hda7      swap           swap     defaults        0 0
/dev/cdrom     /mnt/cdrom     iso9660  noauto,owner,kudzu,ro 0 0
/dev/fd0       /mnt/floppy    auto     noauto,owner,kudzu 0 0

to which I could add the following lines:

/dev/hda2      /mnt/hda2      msdos    defaults        0 0
/dev/hda3      /mnt/hda3      vfat     defaults        0 0

(Note: There are numerous options that could be used in place of defaults. For example, I could mount these partitions as "read-only", in which case I would replace defaults with ro.)

Finally, you can "unmount" a partition by using the umount command. The syntax is simple enough:

umount mountpoint or in our case:

Using mtools with DOS Diskettes

When dealing with DOS formatted floppy disks, there's a program suite called mtools that is pre-installed with most Linux distributions. mtools does away with the need for specifying mount points, options and the actual mounting process. Instead, it does this for you automatically. It also provides a set of commands similar to DOS such as mdir, mcopy, mdelete, and many others. If you're comfortable with DOS, using mtools will be just as intuitive - just add an m in front of most DOS commands. For example:

mdir a:

mdir a:*.txt

To copy a file or files to a floppy disk,
type: mcopy myfile a:
or: mcopy myfile*.doc a:

To delete a file or files on a floppy disk,
type: mdelete a:myfile
or: mdelete a:myfile*.zip

For more information about mtools, check out: https://www.mtools.linux.lu. The mtools manual can be found here: https://www.mtools.linux.lu/mtools_toc.html.

In the Case of Zip Disks

mtools is supposed to work with Zip disks too, but for some reason I couldn't get it to work - at least in the beginning. Instead, I had to rely on using the conventional mount and umount commands. But before I could do that even, I had to figure out what device the Zip drive was assigned to. Unfortunately, this isn't as straightforward as it should be. While one can be reasonably assured of finding a primary IDE hard disk at /dev/hda, IDE Zip drives (the kind I'm working with) can actually be installed in various places, not to mention the fact that there are also several KINDS of Zip drives (i.e. ATA, ATAPI-IDE, SCSI, USB, parallel port).

Knowing that my Zip drive was attached as a slave device to the secondary IDE controller, its logical location should have been /dev/hdd. But not always. After some trial and error, I determined that FAT16 (i.e. msdos) formatted Zip disks showed up at /dev/hdd4, while FAT32 (i.e. vfat) formatted Zip disks showed up at /dev/hdd1. (Incidentally, Red Hat 8's own kudzu hardware inspector sets the Zip drive to /dev/hdd4 in the /etc/fstab file.)

(Important: The vast majority of PC Zip disks you'll find should be formatted as FAT16. For some unknown reason, I have a Zip disk that's formatted as FAT32 - probably something I did. Thus, it's best to consider FAT32 Zip disks the exception and not the rule.)

Anyway, with this knowledge in hand, I'm now able to do this:

Lazy me then added a symbolic link in my home directory to the zip mount point as follows:

But wait. Now that I know the distinction between /dev/hdd4 and /dev/hdd1, and the fact fact that I was doing my testing with a non-standard FAT32 Zip disk not a regular FAT16 Zip, I was finally able to configure mtools to read FAT16 Zip disks (apparently, it still can't read FAT32). What's required is an additional line in /etc/mtools.conf as follows:

drive z: file="/dev/hdd4/index.html"

drive z: file="/dev/hdd/index.html" partition=4

With this configuration change in place, Zip disks can now be accessed simply by referring to them in drive z:. Whew!

Zip Disks With a Dash of X

If you feel that you can't do mtools without a GUI, there's a helper X application called MToolsFM (available from https://www.core-coutainville.org/MToolsFM). Before you use it though, you should tell it about the Zip we toiled so hard to get working. Go to Options > Configuration and set the drives to be displayed as az (figure 1).

With that done, MToolsFM will now be able to handle both floppy and Zip disks (figure 2), and should operate as most file managers do. And like with command line mtools, no mounting or unmounting of disks will be necessary.

Windows NT/2000 NTFS Partitions

Linux is also capable of accessing NTFS-type partitions that are common to Windows NT (NTFS4) and Windows 2000/XP (NTFS5). Unfortunately, my Red Hat Linux v8.0 didn't have this built into the kernel (supposedly due to legal uncertainties). However, RPM's to provide these capabilities are available at https://www.linux-ntfs.sourceforge.net/info/redhat.html. This is also the home for the Linux NTFS project (https://www.linux-ntfs.sourceforge.net).

The first link takes you through the process of selecting and downloading the correct kernel driver. You will need to know your version of Red Hat, its kernel version, and the type and number of CPU's in your computer. Given that my Red Hat Linux v8.0's kernel version is 2.4.18-14 and I have a single i686 type processor, I downloaded kernel-ntfs-2.4.18-14.i386.rpm.

To install it, from a terminal, as root, type:

rpm -Uvh kernel-ntfs-2.4.18-14.rpm

If no error messages appear, you can now mount NTFS partitions just like you did with the previous DOS partitions (save for one parameter change). For example, assuming I have an NTFS partition at /dev/hda1 and have created a mount point at /mnt/ntfs, I would type the following:

mount -t ntfs /dev/hda1 /mnt/ntfs

I can also unmount it or add an appropriate entry into /etc/fstab just like I did previously.

One potential problem with this kernel driver is that it is read-only. If you know a little about NTFS, this probably makes sense - what would a Linux program that's on speaking terms with Windows know about Windows file security and permissions? Even if Windows and Linux COULD work together, this read-only limitation still wouldn't necessarily be a bad thing in my opinion. As a general rule, I wouldn't want my Windows programs to be able to write things into my Linux production areas and vice versa. Having such areas as read-only is far safer. If I REALLY needed to create a read-write area, I'd much prefer to create a shared partition that both Windows and Linux can access (say, a FAT32 partition). If something goes wrong with that partition, I could always delete and recreate it.

(In case you're wondering why FAT16/FAT32 partitions don't have this same problem, neither have security features beyond basic file attributes.)

OS/2 HPFS Partitions

While Linux is also technically able to support HPFS file systems, Red Hat Linux v8.0 again ships without this support enabled. Unlike NTFS though, there doesn't seem to be an "after-the-fact" kernel patch for the 2.4 kernel (only the 2.0 and 2.2 kernels). Thus, the only way to implement this is to recompile the kernel with HPFS support turned on. Because I have yet to experience the joys of recompiling a kernel, I will forego the details of how this is done for the time being.

For further information about using HPFS on various operating systems (not just Linux), check out: https://www.linux.org/docs/ldp/howto/Filesystems-HOWTO-4.html.

Macintosh HFS Partitions

In looking at Macintosh file systems, I'm going to restrict myself to floppy disks. It's probably unlikely that you would ever remove a hard drive from a Macintosh and expect a Linux box to read it in its entirety. Rather, it's more likely that you would ask Linux to read a Mac formatted diskette or a Zip disk containing files/documents.

A program called HFS Utilities (https://www.mars.org/home/rob/proj/hfs) exists that allows you to deal with Mac disks, either from the command line or from an X app. Unfortunately, there doesn't seem to be a Red Hat Linux v8.0 specific version yet, so instead, I obtained hfsutils-3.2.6-7.i386.rpm from https://www.rpmseek.com that was meant for Red Hat Linux v7.1 PowerTools. But it works.

Before it could work though, hfsutils told me that I needed to update my Tcl/Tk libraries to at least libtk8.3.so. Searching on "tcl" at https://www.rpmfind.net, I managed to find tcl-8.3.3-74.i386.rpm for Red Hat Linux v8.0.

Thus, my actual installation involved the following:

I haven't played around with hfs' command line utilities yet, but I did try its X app, xhfs, which I ran from a terminal window by giving the command xhfs&. figure 3 is what the screen looked like after I told the program to open a Mac formatted diskette. The left panel shows the contents of the Mac floppy, while the right panel shows the contents of the current Linux directory.

I created three types of files on the Mac disk: a text file, a Microsoft Word file, and a Microsoft Excel file. (On a hunch, I saved each with a "long file name" and a "short file name".) Copying the files from the Mac floppy to the Linux directory simply involves highlighting the required files in the left panel and then clicking the Copy button to copy them to the right panel (figure 4).

Before copying, though, xhfs needs to make a guess as to the type of file being copied (for on-the-fly conversions, I think). With the text files (short and long file names), xhfs correctly guessed that the files were Text files (duh!) (figure 5). With the Excel files (short and long file names), xhfs again correctly guessed that the files were what it calls Raw Data files (figure 6).

With the Word files, though, it screwed up a bit. It correctly assumed the Word file with the long file name was a Raw Data file. But when it came to the Word file with the short file name, it mistakenly assumed it to be a MacBinary II file (figure 7 ), and files transferred in such a manner could not be opened by OpenOffice Writer on the Linux side. I'm not sure why it makes this mistake, but it's easy enough to manually change the Mode to Raw Data and then redo the copy (figure 8).

Two final caveats:

Even though I arbitrarily restricted myself to Mac floppy disks, HFS Utilities is, in fact, able to handle all sorts of Mac media - floppies and Zip disks, SCSI hard drives, Mac CD-ROM's, etc. I've tried a Mac Zip disk with xhfs, and yes it does work (figure 9). I haven't tried other Mac media though.
It should be noted that the current version of HFS Utilities DOES NOT handle Apple's newer HFS+ file system, nor does it handle the older MFS file system.