• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Disk images: sort of Catch-22 situation

Morrick

6502
In one of my old backups I've found a complete set of 13 disk images for Aldus PageMaker 5.0. I honestly don't know if it belonged to me or was something I got from one of the used Macs I've acquired through the years. The fact is, I can't use these disk images.

Disk Copy 6.3.3 (or its older incarnation, Drop Disk) refuses to mount them. Disk Copy 4.2 successfully transfers the content of the disk images into real floppies -- I have to fool it into thinking they're not 1.44 MB floppies, but the funny thing is this: after creating the floppy and ejecting it, I reinsert it and the PowerBook 5300 tells me it cannot read that floppy.

I suspect the disk images are of 400K floppies. So I pick the oldest Mac in my collection, a SE FDHD, hoping it can read 400K floppies, but no.

So I'm left with 13 Aldus PageMaker installation floppies I cannot use.

Is there some alternative disk image mounter which can at least mount the 400K images? Or that can convert them into self-mounting images?

Any advice would be valuable. Thanks in advance!

Rick

 
I suspect the disk images are of 400K floppies. So I pick the oldest Mac in my collection, a SE FDHD, hoping it can read 400K floppies, but no.
Write them on the machine you want to read them on, the older the better.

Erase (initialise) the disk a number of times before you write the disk image to them.

Disk images won't work with floppies with bad sectors.

 
My guess is that they're ShrinkWrap disk images. Try mounting them with ShrinkWrap or a newer version of Stuffit Expander (5.5)

 
You didn't mention the image file suffix: .img, .smi and other variations. As TylerEss suggests, a more accomplished expander such as StuffIt 5.5 may be called for, or, depending on the age/version of the PageMaker (it is Aldus and not Adobe), an older version such as UnStuffIt 2. You do truly mean disk images, and not .sea or the like (or .smi, which will exist in usable form only in RAM unless you then make disks of them)?

de

 
Thanks, folks, for these first insights and sorry for the lack of further information. Equill -- the files are all .img. Some have the familiar Disk Copy image icons (and FileBuddy identifies them with a "dImg" type and "ddsk" creator), some have blank icons and the type/creator is wrongly identified with a GraphicConverter image format.

I didn't think about ShrinkWrap -- I'll look for it in my archives -- thank you, TylerEss.

I also didn't imagine that StuffIt could handle disk images... I was so accustomed to using it always to decompress .sitted or .zipped archives. Anyway, I just tried with StuffIt Expander 5.5 but nothing happens: when I drag the .img file over StuffIt Expander, the application opens and closes without doing anything.

I'll look for ShrinkWrap and keep you posted. Thanks all, for now.

Cheers

Rick

 
Update: Further attempts at decoding/mounting the images have included the use of the following software programs:

- DiskDup+ Pro 1.0.3 (result: doesn't recognise the image as a valid Mac OS disk)

- ShrinkWrap 3.5 (result: a brief "Analyzing image" dialogue box appears, then nothing happens and the program closes)

- MountImage 1.2ß2 control panel (result: it sees the images, but won't mount them)

- DART 1.5.3 (result: it recognises the images as "Lisa, 400K" [Jesus, this is new!] and correctly writes a floppy disk [i fool it into believing it's one side of a 800k disk]. However, I'm left in the same situation as with Disk Copy 4.2. I can reverse the process, creating a DART image from the floppy, but that image remains quite useless, as the other programs for mounting disk images just ignore it or do not recognise it.)

Grr.

Rick

 
What does Disk Copy 6.3.3 do for you? It's more powerful than 4.2.2, and also more versatile in where it can start and where it can go.

de

 
What does Disk Copy 6.3.3 do for you? It's more powerful than 4.2.2, and also more versatile in where it can start and where it can go.
Sadly, not much. As I wrote in my first post, it refuses to mount the disk images, it gives me a (-8819) error and says that the image is damaged.

Cheers

Rick

 
If that is what 6.3.3 returns consistently, I have to suggest, however discouragingly, that that is what the images may be. They are now more than 13 years old, wherever they may have been living in the interval and through whatever hands they may have passed. You did go through the options in the menu bar rather than rely on dropping the images into the work window? Did the app. provide a checksum?

de

 
they might be raw disk images, made with the dd command on a UNIX box. You might try writing them out to floppies using dd on a UNIX machine or rawrite.exe on a DOS/Win machine...

 
Equill, TylerEss, again thank you for your efforts. It is hugely appreciated.

I did a little experiment:

- Launched DART 1.5.3 and created a floppy out of the first PageMaker Disk image. DART, as I wrote, sees those images as 400K floppy images. It formatted and created the floppy successfully, giving a valid checksum.

- Inserted the floppy with DART still open, and told DART I wanted an image file from that floppy. DART successfully created a DART image of said floppy.

- Launched Disk Copy 6.3.3, instructed it to CONVERT the DART image and it successfully created a valid checksummed Disk Copy image.

- Tried to mount the image converted by Disk Copy 6.3.3 using Disk Copy (duh). Result: Disk Copy says that the volume "can't be read by this Mac OS" (or something along these lines).

After all this, I still suspect that these are actually 400K disk images and that all my vintage Macs are too modern to read them, virtually or physically. I had hoped in the SE, but it has a SuperDrive. This might be a good excuse to look for a Macintosh Plus!! I already have a suitable keyboard and mouse... hmmm) :D

Cheers

Rick

 
You say some have not the right icon and no good creator types. Some disk image formats use the data and the resource fork together to store the disk contents, and if the resource fork is lost, the image et al is useless. I have some images of think c, and they were garbage without the resource fork.

God thanks I've found the disks :b&w:

 
Back
Top