Home Page Back All the Graphics 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):
According to this output, the FAT16 partition is located at
The most common method of mounting a FAT16 or FAT32 partition is to
issue a command like so:
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 to which I could add the following lines:
(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:
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:
To copy a file or files to a floppy disk,
To delete a file or files on a floppy disk,
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:
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
To install it, from a terminal, as root, type:
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
I can also unmount it or add an appropriate entry into
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
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 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:
|