Data Recovery & File Conversions: Director/Projectors by Internet & Jaz

Earlier in July, I made a posting in regards to a data recovery and conversion project involving Syquest cartridges and Macromind/Macromedia Director and Projector files. As it turns out, that was the beginning of an even more involved project with Prof. Dan Boyarksi of the School of Design at Carnegie Mellon University which involved even more SyQuest cartridges, Jaz cartridges and files delivered over the internet. While the methodology behind the file conversions remained the same as that in the previous posting, the presence of internet-based delivery and Jaz catridges posed some new barriers which required some further research. The results are reported in this posting.

Internet Delivery

There are some cases where old files have been actively taken care of, and the medium format has been upgraded over time to ensure the files can still be accessed. This could be as simple as making sure that your files on floppy disks, ZIP disks, etc are copied over to a CD-R, or a hard drive and copies are made over time as the media and interfaces change. While this is great, as it ensures that the files aren’t “stranded” on a media which has become obsolete (e.g. SyQuest cartridges being a prime example), it doesn’t ensure that the files continue to be useful. In the case of the change to the CPU architecture and operating system of Macintoshes, classic executable files are no longer executable, and applications may refuse to import or recognize older files.

As there were quite a few files which had “made the jump” media wise, but were not immediately usable, it was decided that transacting the files over the internet would be the most convenient way of delivering the files for further examination and conversion.

Initially, the files were uploaded to a file-sharing service, and a link was delivered to me. After a quick examination, it was determined that this “direct upload” of the files was not a desirable method of transacting files over the internet as it resulted in metadata loss and loss of the resource fork. Only the data fork remained in the downloaded files. In classic Mac OS files, each file consists of a data fork and a resource fork. Loss of the associated resource fork often results in loss of file type/creator metadata, or even the entire contents of the file in the case of font files where all the data is contained within the resource fork.

To ensure that this data is not lost, it’s necessary to find a way to bundle the data together. Previously, the use of AppleSingle, MacBinary and BinHex were more popular in the days of early internet, email, newsgroups and BBSes for distribution of Apple files as they preserved the resource fork and data fork together in a single file. To use these formats requires encoding the file prior to transmission and decoding the file after transmission and involves the use of third party software. There is an easier way, namely, the use of archival software such as StuffIt! which creates .sit archive files with a compressed copy of everything. Unstuffing the file at the destination restores all of the data.

Unfortunately, these methods are not that straightforward, especially if you have to convince someone to install the software and walk them through as to how to use it. It’s especially complicated by the fact that I’m not a regular Mac OS X user, and I don’t own Apple hardware myself.

Luckily, the inbuilt Compress feature of Mac OS X generates .ZIP archives with the resource fork stored inside the “dot” files. By asking the sender to group all the files and compress them by right-clicking and using the Compress option, a ZIP file is generated with all the information and can be shared online and cross-platform with no risk of breakage. It requires no software installation as well.

After receiving the .ZIP file, I booted my Mac OS X VM and extracted the archive using Mac OS X, thus “reconstituting” the files with no loss of metadata.

The next challenge is to migrate this data from the Mac OS X VM to the Mac OS 7 – Mac OS 9 VMs which will perform the file conversions. Raw .dsk/.hfv can be renamed as .img/.dmg and mounted under Mac OS X, however, they can only mount as read-only as Mac OS X depreciated write support for Mac OS Standard (HFS) filesystem.

Unfortunately, there doesn’t seem to be a way to get around this issue, so instead, we will have to rely on an overlap in functionality, namely that Mac OS 9 supports HFS+ (Mac OS Extended), and thus we can create an image in Mac OS X in the Mac OS Extended format, and mount it under OS 9.

To do this, a disk image is created using Disk Utility with OS X Extended as the file system. Note the use of No partition map and no encryption. Enabling these features can make your image unmountable in the emulator.

osx-image-settings

Once the image is created, you can write files to it, then unmount it and copy it to the system with the emulator and add it as a virtual disk. You can rename it to .dsk/.hfv if necessary.

os904-mounted-ok

A few special system files show up, however, the files are preserved and mounted just fine in Mac OS 9.0.4 with no loss of fidelity. Just remember to make the image larger than you absolutely need to, to make sure the files fit. Further to this, you can also copy the files off from here into an HFS formatted .dsk/.hfv file generated by HFVExplorer and thus migrate the files back to OS 7.

However, I didn’t actually start-off with my process this way – instead I created a .cdr disk image with Mac OS Extended filesystem for burning to a CD in the hope that it would mount directly with no hassle by attaching the .cdr as a virtual drive to the VM. Unfortunately, this was not the case, because the .cdr image included a partition map in the beginning of the image. This appeared to be a GPT/EFI partition map, which OS 9 cannot understand. The image can be rendered usable by truncating the sectors containing the partition map off of the front of the image. In my case, the partition map resided in 0x0 to 0x4FFF bytes, so if you copy from 0x5000 to the end of the image file to a new file using a hex emulator, the resulting disk will mount successfully in the VM.

As a result, transacting files between modern Mac OS X “post-depreciation” of the Mac OS Standard filesystem write support is still achievable provided you have a Mac OS 9 VM to perform the intermediary copy from an HFS+ filesystem to an older HFS filesystem. This works provided the image generated from Mac OS X does not have a partition map. It may work with an older Apple Partition Map, although it was not tested. EFI/GPT are not understood by Mac OS 9, and thus do not work.

Iomega Jaz Cartridges

In addition to SyQuest cartridges, Prof. Boyarksi also decided to mail me two Iomega Jaz cartridges in the off chance that I might have a way to recover the data from them.

2016091914178538

The Iomega Jaz was another external hard disk cartridge format, from the same creators of the very popular Zip disks. It wasn’t as popular as the Zip disks, but offered much more capacious and speedy storage. It was, however, quite expensive and offered 1Gb per cartridge (initially), before upgrading to 2Gb per cartridge. It had a tough time competing with the CD-R/CD-RW drives which became cheap and mainstream several years after introduction.

2016091914188539

Not having ever prior dealt with Jaz cartridges, this post will be a good look at the cartridges themselves. These were 1Gb cartridges, one being originally PC formatted, and the other, originally Mac formatted. The price was US$98 according to the label on the front. It comes housed in a vac-form plastic clamshell which is similar to that of the SyQuest, but the disks are a more compact 3.5″-like form factor.

The clamshell paper inserts were different depending on their factory format.

jaz-outer-mac jaz-outer-pc

They also turned out to be “fold open”, and thus had some promotional material on the inside. They also had two spreads which could be used for notes.

jaz-inner-promo

jaz-inner-note

The cartridges have a pentagonal shape, with a rounded top.

2016091914188540

A label sits over the main body of the cartridge, but provision is also made for a spine label.

2016091914198541

No write protect notches exist on the cartridge. The labels provided appear to be a plastic-type label, on clear plastic backing, which might be a design choice to avoid any paper fibres being developed near the drive mechanism as hard drives are sensitive to dust.

2016091914208546

2016091914198542 2016091914198544

The sides of the cartridge have guidance channels for aligning its insertion into the drive. The left side also has a cut-out notch to open the protective shutter which covers the opening.

2016091914198543 2016091914208547

The protective shutter is a thin piece of metal which slides along a channel in the plastic case.

2016091914218550

Internally, the disk is made of two platters, and thus, four surfaces each holding around 250MB. The density is about double that of a SyQuest EzFlyer 230MB which only had a single platter with two surfaces (if I recall correctly) storing 230MB. This design, of course, necessitates having four heads in the drive and is potentially vulnerable to disk slip/shift in case of shock which could affect the alignment of the two platters relative to each other.

2016091914198545

The underside has the spindle interface mechanism, which has some vague similarities with the SyQuest in terms of the spindle centering “tangs” in the middle, but is otherwise quite distinct.

2016091914238553

The cartridge is constructed with a number of small Phillips screws. Internally, the media is a very light golden brown colour, which is to be expected. There is a mechanism in the lid which has a springy hook to retain the shutter in the fully closed/opened positions. There is also some air-cleaning filters within the cartridge. I do not recommend opening the cartridge, as the shutter mechanism has a tendency to fall apart and require careful manipulation to realign.

2016091914248554

Because it was in no way compatible with the SyQuest system, being a completely different system, I needed to source a Jaz drive to access the data. It was very fortunate that a colleague at the university I was studying at had a Jaz drive he was willing to loan to me to read-out the media.

2016091914338561

The drive, from the top, boasts some visual similarities to the Zip drive, but is a teal green instead of the blue commonly associated with Zip. A window on the top allows for reading the top cartridge label while a cartridge is inserted, just as in the external Zip drives.

2016091914348565

Cartridges are loaded through the front slot, with the front label visible during operation. An eject button is provided with an emergency eject hole underneath the loading slot. Two LED indicators are also provided, as per the Zip drives.

2016091914348563 2016091914348564

There’s nothing particularly interesting about the sides …

2016091914308559

The rear has two HD-50 connections for SCSI, with a termination switch that features three settings (on, auto, off). A SCSI ID selection push-switch is provided, along with a power switch and power input.

2016091914298558

The underside features the model number V1000S, and some rubber feet.

2016091914298556 2016091914298557

The power supply provided features both 12v and 5v outputs, although the connections were not determined. Because the unit was on loan, it wasn’t torn apart for examination …

2016091914288555

Of course, just having the drive was not sufficient. The problem was how to connect the drive to the computer. As I only had a DB-25 connector on my SCSI card, and DB-25 to Centronics-50 cables, I couldn’t directly connect the drive to the computer. As SCSI cables get rare, it’s almost impossible to buy the cables you need, and even if you could, it would be cost-prohibitive.

Luckily, thanks to my colleague, he was also able to find an HD-50 to Centronics-50 cable, so I used one SyQuest external enclosure to “join” the Centronics-50 to Centronics-50 to make the bus complete to the DB-25 connection on the controller. He was sure he had an HD-50 to DB-25 cable, but he was not able to find it. But it does illustrate the challenges that one faces with SCSI – connectors and cables can be a challenge to obtain.

With the interface complete and functional, recovery was done using the same Linux recovery machine using ddrescue. The Jaz cartridges did both require some level of retries to recover all of the data, however, no data was ultimately lost. It seems that dust may have settled on the disk, or some areas had become magnetically “weak”, resulting in a number of retries to return the data. Quick experiments using sginfo showed that the drive does not return GLIST or PLIST data, which was unfortunate, as it seems there is no way to assess the health of the cartridges without (possibly) resorting to Iomega’s own tools.

Conclusion

Delivery of “classic” Mac OS files with resource and data forks by internet transmission is complicated by the fact that many existing file sharing utilities may not correctly retain the data in both forks when files are uploaded/downloaded from the service. This is not such a major issue, as Mac OS X based applications are moving away from the resource/data-fork model, and the loss of the resource fork and associated metadata isn’t critical to the functionality of the files which can still be identified by extension. However, with classic files, this can pose major issues and require extra work to overcome.

A method to encapsulate both forks for transmission as a single stream is to archive the files. Mac OS X’s inbuilt “Compress” feature creates ZIP files which retain the information, and has the advantage of not needing third party software such as StuffIt! does. This can be suitably “reversed” by unarchiving on a receiving Mac OS X based machine (or virtual machine in my case).

A complication is that the unarchived files cannot be directly deposited into an HFS filesystem (i.e. that used natively by “classic” Mac OSX and now termed Mac OS Standard filesystem) as OS X has removed write support for it. Thanks to the overlapping support for Mac OS Extended (HFS+) with Mac OS 9, it is possible to create image files under OSX that will mount under OS 9, and then can be copied over to an HFS volume if necessary for use under Mac OS 7.

Dealing with Jaz cartridges is conceptually identical to dealing with the SyQuest cartridges, with the difference being the hardware required to read the cartridge. Thanks to a colleague, I was able to loan the drive for a short period to recover the data, and proceed with recovery in much the same way as with the other media. I also had an opportunity to examine the structure of the cartridge itself, which marks the first time I’ve dealt with Jaz media and drives.

In all, it was another successful project, which resulted in further understanding of how to directly exchange data between Mac OS X and classic Mac OS in emulators without any loss of resource fork data or use of third-party applications such as StuffIt!

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Tech Flashback and tagged , , , , , . Bookmark the permalink.

7 Responses to Data Recovery & File Conversions: Director/Projectors by Internet & Jaz

  1. Mark says:

    I used to always use the OS X “compress” feature to make .ZIP files out of folders for transfer to Windoze boxes. Since El Capitan (El Crappytan?) compression has fairly regularly bombed out complaining about compression errors (usually on simple .WAV files). And if it didn’t bomb out, it could produce .ZIP files that would not de-compress. Always check your compressed archives to make sure they are not borked…

    • lui_gough says:

      Good advice, but also if true, it seems quite troubling indeed since .ZIP compression algorithms has pretty much been semi-standardized, there really isn’t much to it at all. If the OS can’t even make proper .ZIP files anymore regardless of the input … something is really wrong. Are you sure it’s not your machine? Unstable hardware (primarily CPU, RAM and also storage drives) is well known to cause computational errors that will result in files that fail to decompress with checksum errors, and is one reason why I have used WinRAR’s benchmark feature as part of a stress test of hardware as it compresses-then-decompresses and verifies the data is correct as a check of the hardware.

      I certainly hope it’s not a sign of the future, as it sounds like most of Mac OS X’s recent releases have been buggy in more than a few minor ways. I wonder if Sierra will change anything – maybe we will lose even more options?

      – Gough

  2. Mark says:

    Unfortunately, I also tried compressing the same folder on a MacBook Pro (2008) and got the same result. Both machines (the other is a quad core Mac Mini 2012) are fully updated. I have not tried it on a 2010 Mac Mini or my 2005 Power PC G4 mini (which dual boots OSX 10.5 and Ubuntu Mate)

    The real nasty is when it “succesfully” makes a borked archive and you are not aware any problems until you try to un-compress it.

    Another bonus feature of El Capitan is glitches in the printer driver for the HP 7310 printer… random “filter error” crashes. These are usually recoverable by printing the document again. The compression error is repeatable and data-dependent. Also they dumbed down the firewall log and you can no longer see who is attacking your system. And don’t get me started on the dumbed down disk utility app… (at least you can patch Yosemite’s disk utility to work on El Capitan).

  3. Mark says:

    Well, even with the latest “improvenents”, it “just works” a hell of a lot better than Windoze. I do really hate the dumbing down stuff and hiding of previous useful / obvious features. And they don’t try to force unwanted OS’s and updates down your throat. Plus, I’ve never had an OS X update bork my machine… I can’t count how many times Windoze has done that.

  4. Gerry says:

    “Because the unit was on loan, it wasn’t torn apart for examination …”

    …but nevertheless hopefully cleaned before data recovery ;-).

    • lui_gough says:

      It was very much dustier on the outside prior to the photos as it had been in a storage unit for some time … but yes. It was cleaned with care … and quickly examined through the drive door in case there were any loose bits internally or dead insects etc.

      – Gough

Error: Comment is Missing!