Friday, January 01, 2010

Apple Were Right To Ditch The Resource Fork.

I have just finished some unsolicited, painstaking work in recovering from one of the weirdest computing accidents I have ever had in my entire computing life on the Macintosh, where I unexpectedly happened to trash two of my most important hard disks on my otherwise trustworthy computer system!

Boot Camp for Mac OS X 10.6 Snow Leopard allows you to mount HFS Extended volumes as read-only volumes in Windows XP or Vista. While this is a real convenience to those who still have to endure Windows for a little while more, there is a small detail to be aware of with this feature. While the volumes are presented as read-only through the HFS filesystem drivers on Windows, you can still damage them by invoking the various disk management tools in Windows and applying them to your HFS volumes!

This is also true for the Macintosh anyway, where mounting NTFS filesystems as read-only doesn't protect them from damage by users of Disk Utility or diskutil(1). So there's nothing bizarre in how Windows can treat your disks outside of Boot Camp's HFS drivers.

What caught me by surprise though, and this is where I show off my stupidity in all its glory, is that a simple act of re-assigning drive letters for HFS volumes mounted as read-only in Windows is what clobbered the disks! Apparently, the Computer Management tool that provides the means to manage your locally attached hard disks in Windows needs to alter the disks themselves when manually assigning drive letters to volumes. Re-assigning the drive letters to your preferences in Windows does indeed work, even for read-only HFS volumes, but you'll get a big surprise when you reboot back to the Macintosh world... where the volumes to which you have assigned drive letters in Windows will disappear on the Macintosh!

Yep, that's right—the volumes' headers will be clobbered! Disk Utility shows the volumes that once were HFS Extended volumes to be vaguely FAT32 volumes, and will refuse to mount them.

So, I had started on the long recovery process of booting back into Windows, and copying all the files back from the broken HFS volumes onto new NTFS volumes, and going through the rigmarole of dealing with incompatible pathnames, unreachable directories and, of course... files with missing resource forks.

Being unable to read resource forks from files on non-Macintosh systems is a reason why Apple decided to ditch resource forks in the first place, and for the first time, I have come to appreciate this decision. Currently, the only kinds of resource files that Mac OS X makes are aliases, and clippings—files which are created by dragging clipboard data from an application onto a Finder container object, such as the desktop or a Finder window—which were probably the last remnants of Mac OS 9 left to be re-engineered. Aliases are probably the most likely type of files that contain resource forks, and since Windows can't read the contents of such files—they appear as files of zero bytes in length—unless you can re-create the aliases, you've lost them forever. I'm going to have a hard time recovering just some of those lost aliases!

I also managed to lose some AppleScripts I have written on the older systems, since AppleScript also saved compiled scripts in resource forks. Later versions of AppleScript can compile to script bundles rather than in resource forks, so these have been taken care of to some extent, because all the files created by AppleScript will appear in the data forks of these files. But unfortunately, these changes to AppleScript won't save the scripts I've lost. The same thing goes for older Internet Location files, which had contained URLs I wanted to save at some point.

Thankfully, most files that Mac OS X applications write are either data-fork-only bundles, or plain data-fork-only files. So Windows was able to copy them over to an NTFS filesystem without much data loss (extended attributes and security metadata are the only things left to lose, which the HFS filesystem driver under Windows doesn't preserve, and is probably something that won't be of concern).

To be fair, NTFS itself doesn't have these pathname limitations... it's more like Windows Explorer or the underlying filesystem drivers that have these seemingly stupid, unaccommodating issues with pathnames.

And then, once as much data as possible has been copied onto the NTFS volumes, the broken HFS volumes can be re-initialised in Mac OS X and then the files on the NTFS volumes can be copied back onto the newly initialised HFS volumes. The copy from NTFS to HFS will be much easier because there are no hidden forks to worry about, and more importantly, there aren't any of the pathetic filesystem pathname limitations that NTFS has for the Macintosh to deal with.

While I have been able to recover most of the data from this rather viscous accident, there are a few things I have come to realise along the way out of this ordeal:

  • resource forks are not the place for storing data that a user can create and is critical to have readable for document reconstruction by any system—use applications or techniques that only make data-fork-only files,
  • despite what your filesystem can actually do, you should store your data, if you can, in such a way that pathnames conform to FAT32 filesystem specifications so that you do not run into interoperability issues when transporting your data from one filesystem to another, and
  • if there is an absolute need to store data by means that violate the above two criteria, save them in a disk image file whose name, location and content fits the above two criteria.
The concept of using the data fork to store resource data was a consequence of the OpenStep Specification, where the host operating systems BSD UNIX, Solaris, HP/UX and Windows 95/2000 didn't have dedicated facilities for storing resource data like the Macintosh did.

If it weren't for Apple's insistence for not using resource forks in files made by Mac OS X applications, I would have been in a pickle! The ability to store user information on any filesystem and host operating system without potential for corruption or data loss is an asset that benefits everybody using any system they choose, particularly when filesystem drivers for "foreign" operating systems are becoming more commonplace. As of Mac OS X 10.4 Tiger, read-only NTFS filesystem drivers enable Macintosh users to read data from within files on disks formatted on Windows systems, and now Boot Camp for Snow Leopard provides the inverse capability for reading files on HFS disks under Windows.

But the picture is not yet complete. Even for Snow Leopard, Apple has yet to change the way the Finder saves aliases and text clippings. Until this happens in a future system release, then I don't recommend saving clippings to a filesystem and expect them to survive the worst. With aliases, though, because I imagine that people would use them indispensably, the loss of these files can be disastrous, and time consuming to repair. Apple still have a little bit of homework to do here.

And if you have any older 32-bit applications that use the Carbon libraries, chances are your applications may still be making files that contain resource forks. Back up these files on external media formatted as HFS Extended volumes to preserve the contents of these files' resource forks, since these files may probably only be useful to Macintosh anyway. And if you find an application which is using resource forks for the wrong purposes (eg., it is saving data which may be useful if it were moved to another kind of system, but is inaccessible there), then it's time to move onto another [version of the] application, and ditch the old one.


Labels: , , ,