This page is a wiki. Please login or create an account to begin editing.


6 posts / 0 new
Last post
Jatoba's picture
Offline
Joined: 2018 Apr 16
Opening "mysterious" .img file

Heya. As some of you may know, I was gathering every Mac demoscene demo ever, and I came across a demo that was compiled for literally dozens of platforms. Among them, our beloved actual, "classic", real Mac OS.

In this page, we have our Mac files, "planethively_macos-classic.img" and "planethively_macos-src.img". Thing is, I cannot mount these image files, no matter what I do. Here's a Pouet (a demoscene website) page with comments, though I found nothing actually useful there.

Now, onto the troubleshooting. On Mac OS 9.2.2, I tried mounting the .img files with Toast 5.2.3, Virtual CD/DVD-ROM Utility 1.0d3 and Disk Copy 6.x (all variants). On Mac OS 8.1 using Basilisk, I tried Disk Copy 4.2 (and all unofficial variants). No success at mounting. I also tried Mac OS X Tiger PPC, no luck. I even tried mounting it on Windows, but Windows wouldn't recognize it.

I also tried "decompressing" the .img files with ShrinkWrap 3.5, StuffIt Expander 7.0.3 and 5.5.1, and, on Windows, with 7Zip. None worked, either.

I checked the Creator/Type codes of the .img files, and they seem to be GKON (Creator) and IMGg (Type). Seems that's associated with GraphicConverter, although it shouldn't be. Looking for those creator-type codes in the Garden, I came across this page with someone having the same kind of trouble, except that person's problem was solved with ResEdit (to change creator & type codes), which didn't work for me, because these .img files have no resource fork (I tried). Not sure how I go changing the creator & type codes otherwise. (Other than using Virtual CD/DVD's type changing app, but that didn't allow me to mount these images still.)

tl;dr I can't mount two .img files.

So..... Tips? Ideas? Think those images are corrupted? Anyone willing to take a look?

Comments

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Your Finder is erroneously placing GKON (Creator) and IMGg (Type) onto them as it doesn't know what they are for - it assumes because of the "img" suffix they may be some kind of graphic, so you get that Creator and File type tacked on.

I suspect that they are Disk Copy 6.x files (compressed format). They are also a good example of why Disk Copy 6 img files (or whatever classic Mac binary data they are) should be archived as ".sit, .bin, or .hqx" before adding them to a web server.

Any resource fork was stripped from the files by simply uploading them unarchived to that web page. Which means (because the resource fork is missing) they are unrecoverable.

You can dump those files onto BBEdit lite to view their Data Fork content. I can see they contain PPC data (contains "Joy!" header) and you can read some of the content as there is a smattering of English in there amongst the raw data.

Unusable tho'.

Jatoba's picture
Offline
Joined: 2018 Apr 16

I feared this would be the case. Thanks for the clarification. Hopefully the issue will be fixed if this is brought up to the authors' attention by posting on their forums and in that Pouet page.

Edit: Welp, I did it. Asked it both in that forum and on the Pouet entry. More than that, only if I try compiling what's on GitHub and/or try to track down and contact whoever worked on the classic Mac port. I think I'm good for now. Laughing out loud Tired

24bit's picture
Offline
Joined: 2010 Nov 19

Not sure whether its worth the hassle or possible finally, but what if a generic resource fork - say from an empty 800k img - could be added to the damaged .img with a utility like SUM II Tools ?

Screenshot-2019-05-04-at-12-51-43

mrdav's picture
Offline
Joined: 2011 Dec 3

--->generic resource fork<-----

I doubt that this would work. My understanding is that the resource fork of a compressed Disk Copy 6 image contains essential information about the compression, and that this is usually specific to the file in question and is essential for mounting the image. But no harm in trying.

24bit's picture
Offline
Joined: 2010 Nov 19

Agreed mrdav, I did not think about compression in DC6. Sad