kmos: Saving to non-HFS+disks from OS X & OS 9

Saving to non-HFS+ disks from OS X and OS 9

Question: I saved files to a hard drive/zip disk/floppy drive from my Mac that was running OS 9, and now when I try to access those files from my Mac running OS X, the files appear as generic documents, or as "UNIX executable files. What can I do?"

Answer:
The internal hard drive on your Mac is likely formatted as HFS+, which is the native Mac format. The HFS+ supports "forked" files, where files can contain two separate parts or forks: the data fork and the resource fork. In addition to this, the Mac also records "metadata" information about files, such as a file's creation or modification date, label, comments, file type, and creator types, etc. A file's file type is a four-character code, such as 'APPL' (application), ''PDF ' (PDF document), or 'TEXT' (text document), which is used to help identify the type of information that a file contains. A file's creator type is a four-character code, such as 'hook' (iTunes), 'fez!' (iChat), or 'sfri' (Safari), which is used to identify which application a particular file "belongs" to. This metadata information is stored in the HFS+ disk directory (not in the file's resource fork).

Many other platforms, like Windows, use a "flat" file system such as FAT32, which does not ordinarily support forks or the rich Mac metadata for files.

Both OS 9 and OS X, however, attempt to preserve the resource fork and HFS+ metadata information when writing files to file systems that don't natively support this information.

OS 9 uses, for lack of a better name, a "RESOURCE.FRK & FINDER.DAT" method to preserve this information when writing files to PC (FAT) formatted floppies or other drives. Use the following images as a reference while reading the next few lines. In this method, for the files in a given folder, the data fork part of the file is written to a file with the same name as the original file (or in very old versions of Mac OS, such as OS 7, an "!" was placed at the beginning of the name). The Mac metadata information, like the file type and creator type information, is stored in a file in that folder named "FINDER.DAT". The corresponding resource fork information for the files in that folder are stored inside of an invisible "RESOURCE.FRK" folder. The files in this folder are named in the DOS 8.3 filename method. Each file in the main folder that has resource fork information will have its corresponding file inside of the "RESOURCE.FRK" folder. The "FINDER.DAT" file serves as a database that links these two parts of a file together. When you place these disks in your Mac (running OS 9), you won't see these files, however, as OS 9 makes everything seem as though you were writing the information to a Mac (HFS+) formatted drive. If you go to a PC though, and insert the disk, you'll be able to see this "RESOURCE.FRK & FINDER.DAT" structure as shown in the images referenced above. Notice the "dimmed" state of the "FINDER.DAT" file, the "RESOURCE.FRK" folder, and the various other OS 9 "System" type files, such as the "Desktop DB", etc. These files have their invisible bit set so you won't be able to see them very easily in OS 9, nor in OS X (unless you enable the Finder's hidden option to do so).

OS X also uses a method to preserve the resource fork and HFS+ metadata when writing files to PC (FAT, NTFS), UFS, or other non-HFS formatted drives: the Apple Double format. In this method, the data fork of a file is written to a file with the exact same name as the original file. The resource fork (if any) and HFS+ metadata (if any) is then written to a file that has the same name except for a "._" in front of it. This "._file" will have its invisible bit set so it may appear dimmed when looking at it from a PC. When you copy these files from a PC formatted disk onto your Mac OS X disk, the 2 files are joined back together into their original form.

Unfortunately, these 2 methods are quite different and are not cross-compatible. When trying to read files, both OS X and OS 9 will be looking in the wrong place for the HFS+ metadata (namely the file type and creator type information) and for the resource fork information. Trying to copy a resource-fork-based file over to the PC disk from OS 9, and then connecting to that disk from an OS X Mac in order to copy the file from the PC to the OS X machine will not work. OS X won't know how to use the RESOURCE.FRK and FINDER.DAT method of writing or reading files, nor does OS 9 know what to make of the Apple Double format and the 2 separate parts of the files.

This same type of situation can arise if you used a PC server to which you saved files to from an OS 9 computer. Since OS 9 and prior primarily only support networking through the use of the AFP protocol, the PC server would most likely have to be running some sort of AFP "emulation" for the Macs to be able to connect. For example, Windows 2000 Professional (and possibly Windows NT as well) use "Services for Macintosh" (SFM ) to provide access for Macs through the AFP protocol. The NTFS file system that those Windows OS'es are based on support the use of forks, and the "Services for Macintosh" feature uses its own proprietary method of dealing with the Mac HFS+ metadata and resource fork information. Unfortunately, just like the 2 methods above are incompatible, it's possible that this would be an incompatible method too.

To make sure that files saved from an OS 9 machine to a PC server running SFM appear correctly when connecting to that PC server from an OS X machine, be sure to continue to connect to the server using the AFP protocol. Since OS X has automatic built-in support for the SMB protocol which PC's use by default, it's possible that you could connect to the PC using either AFP or SMB. When you connect via AFP, you're letting the PC manage the resource fork and HFS+ metadata information itself. In a sense, your Mac is "fooled" into thinking that this server is an ordinary HFS+ type format, when it's actually an NTFS formatted one. When you connect to the PC server via SMB, on the other hand, the PC won't be using this Services for Macintosh deal, and therefore won't offer to manage the resource fork and HFS+ metadata information itself. As a result, your Mac knows enough to use the Apple Double format to preserve this information. Unfortunately, of course, when you connect via SMB, you won't be able to properly access the files that were written to the server in the AFP/Services-For-Macintosh method. The files that you do manage to access won't have their HFS+ metadata information (e.g. file type and creator type). Any of those files which don't then have a filename extension, will be "undefinable" in a sense, since your Mac needs at least one of those 3 items for a file to be recognizable. So, without this information, the Finder then looks to the file's executable bits, and if they're set, it then assumes that the file is an executable file. This image shows an ordinary example of where this same behavior occurs, such as for the Mach-O executable file of the iTunes application.

Possible solutions/workarounds:

One possibility, for example, would be to, from a Mac running OS 9, copy all the information from the PC file server or PC formatted disk onto some HFS+ formatted disk, whether that be some other sort of central Mac server or the local hard drive of the OS 9 machine itself. Then reboot that OS 9 Mac into OS X, and copy the files back onto the PC file server or PC formatted disk. The files should then be written to that disk or server in the "OS X method", and should then be properly accessible by any Mac that's running OS X. Unfortunately, of course, that means that you'll no longer be able to properly access those files from OS 9. This would definitely create problems if you have a mix of Macs running OS 9 and OS X.

Another alternative would be to avoid the problematic PC format as the "middle man". You'll need to, again, from a Mac running OS 9, copy all the information from the PC file server or PC formatted disk onto some HFS+ formatted disk, whether that be some other sort of central Mac server, portable disk (floppy disk, CD-R, etc.), or the local hard drive of the OS 9 machine itself. Then reboot the OS 9 Mac into OS X, or connect from an OS X Mac to the OS 9 machine, and then access that disk or server. This will avoid the problematic PC format.

Feel free to vote for this post by clicking the - or + buttons above.

Hope this helps....