Best way to archive vintage Mac floppies & CD's to images

[LaPorta]

It could possibly be storage conditions. What kind of environment have they been in for the past 30+ years?

 

[pcamen]

Varying.  Some of them came from a guy that had stored 30 years worth of Apple computers in his garage mostly in plastic tubs but probably moved around over the years.  Some came from eBay.  No way of knowing really. 

 

[LaPorta]

Only from personal experience, I know my floppies I would guess, on average, had probably less than 5% failure rate for all the ones that I have (those that failed I threw out a few months ago). I have found consistently (with only a few exceptions), that the mid 80s, heavy plastic, 800k disks have the lowest failure rate that I have personally seen. The most failures I have seen are the “AOL 3.0” install disks we all got back when, which is not surprising since they were probably bottom barrel disks. I know for a fact that almost all disks I have have been in climate and moisture controlled environments for the past 20+ years.

 

[pcamen]

Here's an interesting problem.  Making images of CD's with DC 6.1.3 ... I can make a read only image or a read only compressed image.  The read only image will be 700m even if there is very little data on the CD, so I chose read only compressed, but it takes _forever_ to complete, due to the slow processing power of the era.  I am running this on a PB 540c. 

What is a better solution? 

I suppose something with a full 040 would be better?  Does compression involve a lot of floating point calculations? 

 

[Cory5412]

That or using a PowerPC Mac for DC6 CD images. 

Curious: Have you tried using DC6.3 on either a 68k Mac or a PPC Mac? 6.1.3 isn't the terminating version and I'm struggling to remember if there was some reason to use that verison or if that was just what you happen to have.

On a positive note, I opened my shrink wrapped copy of Alice Through the Looking Glass and it imaged fine.  I know there are other disk images but no flux image that I know of.  @Cory5412 I seem to recall that you had asked me for a flux image of that game in a discussion about those of us archiving disks uploading them to VTools.  I can't find the discussion now.  Are you still interested?  

In general - I'm interested in in anything being uploaded to VTools!

I know you and I have an active PM session where I was going to give you an account on a separate system I have, so we should handle that there, too.

I need to decide soon if I am going to reformat VTools "soon" or if that's further off, yet, before building more accounts, however. As part of that, I should probably replicate the setup on my blue-and-white or beige G3s so I can confirm I'm documenting and building everything correctly.

In case it bears discussion, on the proper way to archive software (what all to include), Here is what I am doing:

In terms of the actual data on VTools, I think that whether or not I want flux images to be there really depends on how big they are. The point of VTools, and the way I'm running it, is that system 7.x-9 (and up through 10.6) Macs can connect directly to it using AFP/IP.

The trouble is that as a Classic Mac itself, VTools has file size limits, file name length limits, and there's a practical upper limit to the number of disks I can reasonably attatch. (Plus if files got big they would be more annoying to organize.)

I believe either @Alex or @balrog (probably both) and perhaps someone else I am forgetting was advocating flux images primarily for use in Archive.org or another more modern-hosted archive.

My personal vision for a VTools folder was mostly going to be, within each particular collection for a major version of a piece of software:

• Installation media
  
• Relevant patches
  
• Installation media for different minor versions, if relevant (i.e. ClarisWorks 5/ClarisWorks 5 Business/AppleWorks 5)
  
• Notes file with metadata and information (mostly, text-transcription of things like box information, requirements, activation, special instructions (quark 3/4 piracy), serial numbers.)
  

Documentation and box art would be a huge plus, and, again, depending on what filesizes look like, I'm not at all opposed to things like bin/cue images for more complicated games (the dual-platform appleworks 5 release, for example) , flux images for diskettes, box art, CD/diskette scans, etc.

The gotcha really is thinking about organizing for both types of repositories at once.

If organizing VTools becomes too painful, I can move it over to, say, a Linux+Netatalk2 or Windows NT4/2000/2003 virtual machine, which should allow for some flexibility in terms of managing actual storage. (though I'd need to see what Windows 2003/2005 are like in terms of support for big disks, because there's a real chance that they'll have the same problems ASIP6 does.)

 

[uyjulian]

Here's an interesting problem.  Making images of CD's with DC 6.1.3 ... I can make a read only image or a read only compressed image.  The read only image will be 700m even if there is very little data on the CD, so I chose read only compressed, but it takes _forever_ to complete, due to the slow processing power of the era.  I am running this on a PB 540c. 

What is a better solution? 

I suppose something with a full 040 would be better?  Does compression involve a lot of floating point calculations? 

Disk Utility/hdiutil on modern macOS can create CD images in NDIF format.

 

[LaPorta]

Here's an interesting problem.  Making images of CD's with DC 6.1.3 ... I can make a read only image or a read only compressed image.  The read only image will be 700m even if there is very little data on the CD, so I chose read only compressed, but it takes _forever_ to complete, due to the slow processing power of the era.  I am running this on a PB 540c. 

What is a better solution? 

I suppose something with a full 040 would be better?  Does compression involve a lot of floating point calculations? 

For sure it doesn't take anywhere near that with DC 6.5b whatever on my PT Pro with G3. I think that the PB is your true limiting factor.

 

[pcamen]

For sure it doesn't take anywhere near that with DC 6.5b whatever on my PT Pro with G3. I think that the PB is your true limiting factor. 

It's what I had that could easily be moved into my office for some quick archiving.  Wait, silly me, I have a bunch of Lombard PBs.  I'll try that instead.  The poor 540c is still going some two and a half hours later on the one CD. 

 

[Cory5412]

I mean, that's dedication, and to be honest it's the kind of thing I'd do "haha just because, fun!" (and then copy it over localtalk)  but a faster computer would make the task go faster. 

I dont' know the details of how dc6 does compression so I can't say what you'd do best to focus most on (i.e. "a 7200 with a SATA hard disk is fine because this is an i/o bound task" vs. "get you a 1.5GHz mac mini for that sweet CPU boost")

 

[pcamen]

The Lombard was able to do it in 30 minutes.  For kicks, I also did the same thing using my Apple CD 300, didn't take that much longer, maybe 40 or 45 minutes (dinner was ready so I didn't see it through to the end). 

Must say though the PB CD drive is WAY nosier than the 300; that thing is quiet.

 

[pcamen]

@uyjulian is the NDIF / dmg image disk utility creates the same format as the img file that CD 6.x creates?  In other words, do I just have to rename the .dmg extention to .img and I have the same thing that I create with DC 6?

 

[nglevin]

Mac OS X's command line hdiutil is pretty solid. It's the command line tool that Disk Utility is invoking under the hood when dealing with disk images of any form.

There's a convert option under `man hdiutil` that describes its capabilities as such:

convert image -format format -o outfile

                convert image to type format and write the result to outfile.

                As with create, the correct filename extension will be added

                only if it isn't part of the provided name.  Format is one

                of:

                      UDRW - UDIF read/write image

                      UDRO - UDIF read-only image

                      UDCO - UDIF ADC-compressed image

                      UDZO - UDIF zlib-compressed image

                      ULFO - UDIF lzfse-compressed image (OS X 10.11+ only)

                      ULMO - UDIF lzma-compressed image (macOS 10.15+ only)

                      UDBZ - UDIF bzip2-compressed image (Mac OS X 10.4+

                      only)

                      UDTO - DVD/CD-R master for export

                      UDSP - SPARSE (grows with content)

                      UDSB - SPARSEBUNDLE (grows with content; bundle-backed)

                      UFBI - UDIF entire image with MD5 checksum

                      UDRo - UDIF read-only (obsolete format)

                      UDCo - UDIF compressed (obsolete format)

                      RdWr - NDIF read/write image (deprecated)

                      Rdxx - NDIF read-only image (Disk Copy 6.3.3 format;

                      deprecated)

                      ROCo - NDIF compressed image (deprecated)

                      Rken - NDIF compressed (obsolete format)

                      DC42 - Disk Copy 4.2 image (obsolete format)

                In addition to the compression offered by some formats, the

                UDIF and NDIF read-only formats skip unused space in HFS,

                APFS, ExFAT, and MS-DOS (FAT, FAT32) filesystems.  For UDZO,

                -imagekey zlib-level=value allows the zlib compression level

                to be specified a la gzip(1).  The default compression level

                is 1 (fastest).

 

[LaPorta]

The above always makes me ask the question: "why in the world doesn't someone just make a GUI application with all those options?"

 

[nglevin]

That's kind of what Disk Utility is... was?   It hides most of the sharp edges from you. Not very well, but it does

There is a secret user defaults option that exposes some of these formats in Disk Utility. I don't know if it's useful for the newer, simpler post-El Capitan Disk Utility. I turn it on all the time on Tiger/Leopard.

I do recommend reading through that man page, though. Down at the bottom is some really neat history and reasoning behind the progression from Disk Copy 4.2 to DART to NDIF, through the UDIF format that OS X started using.

 

[uyjulian]

@uyjulian is the NDIF / dmg image disk utility creates the same format as the img file that CD 6.x creates?  In other words, do I just have to rename the .dmg extention to .img and I have the same thing that I create with DC 6?

NDIF disk images are different from UDIF disk images. You can use "hdiutil imageinfo /path/to/image.img | grep 'Format Description:'" on the Terminal to check the format. Be aware that macOS versions 10.7 and newer removed support for reading/writing legacy formats; only conversions are supported.

 

[pcamen]

I took a CD and imaged it using both Disk Utility and Disk Copy 6.3.3.  Here's what hdiutil says about the format:

From Disk Utility compressed format:  UDIF read-only compressed (zlib)

From Disk Copy 6.3: hdiutil: imageinfo failed - legacy image should be converted

Hmm.  It won't handle a "legacy" NDIF image anymore; that sucks.  htiutil does support converting to NDIF images though, still.  Here are the formats it supports:

                      RdWr - NDIF read/write image (deprecated)
                      Rdxx - NDIF read-only image (Disk Copy 6.3.3 format)
                      ROCo - NDIF compressed image (deprecated)
                      Rken - NDIF compressed (obsolete format)

So, would I be looking at ROCo or Rken?  I took my DMG and converted to both of them.  On 9.2.2, all three (original + two converted ones) are identified as "read only disk image" in the finder.  Both mount fine in the finder.  All three are just a few bytes different in size. 

Just for kicks I also tried to mount or open the DMG image in 9.2.2, without success. 

 

[nglevin]

Rken is an NDIF image compressed with Apple's proprietary KenCode codec (check the section on New Disk Image Format from this excellent TidBITS article), which to my limited knowledge hasn't been reverse engineered unlike some other forms of compression.

ROCo should be more future proof.

 

[pcamen]

Good, progress then.  Seems like with the Applesauce and hdiutil, I should be able to handle all the media on my modern mac for expediency.  Now I just need to do the work; I've got many bins of Mac floppies and CD's as well as a bookshelf full of boxes stuff, and a bunch of Apple II disks as well. 

 

[LaPorta]

Took me a good 2-3 months just to make floppy and CD images of all my stuff, and that was just Disk Copy images.

 

[uyjulian]

If you have multiple CD or floppy drives, you can use them at the same time to rip your CDs and floppies faster.

... on macOS using hdiutil, you can have multiple operations running at the same time. I'm not too sure about classic Mac OS and Disk Copy 6.3.3, so you may need to have a machine per drive instead of attaching the drives to one machine..