Is it possible to expand a HFS diskimage?

[razo]

Hi, I have a diskimage of a zip-disk containing an obsolete, registered application. The only way to run this application is to run it from the diskimage on a SCSI2SD drive on my ColorClassic. But the diskimage is only 250mb big and I want to use the full capacity 2Gb of the SCSI2SD drive. Is it possible to expand (perhaps pad with zeroes at the end of the file?) this disk image so that it gets a size of 2 Gb, preferably using OSX/Terminal application?

(I made the diskimage using an external scsi enclosure and usb-scsi adapter on my iMac with the Terminal application using the DD command).

Thanks

 

[tanaquil]

I don’t understand. Why don’t you load the app from the disk image and use the rest of the disk space as normal? It’s just a file like any other. Use an appropriate program to mount it (Disk Copy or Toast or whatever). 

I must be be missing something. 

 

[Gorgonops]

I'm kind of scratching my head at why you can't simply drag the contents of the current disk image to another disk  image, say by mounting both in an emulator. Both MacOS and most classic applications take pretty well to simply having their folders dragged to a new disk. Does the application in question include some sort of copy protection to prevent that?

Off the top of my head I'm pretty sure growing an HFS image is going to be a nonstarter, at least if it's regular HFS and not HFS+. Regular HFS had that limitation of only having a 16 bit cluster allocation table so beyond a certain point the size of the file allocation blocks would increase. Thus simply padding the end of the partition with zeros and changing the file allocation structures to make it think it has "more clusters" isn't going to be an option; *every* file on the disk would have to be rewritten to fit in the new larger clusters necessitated by the 16 bit limit.

 

[razo]

Yes, that´s right - it has a special kind of copy protection so that only copying the file doesn´t work. It is only this applicationfile that is important on the disk.

 

[Gorgonops]

About the best thing I can suggest is if having multiple partitions is an acceptable way to get more use out of the device you might be able to do something sneaky like modify the Disk Label (IE, partition table) on the disk so instead of having a single 250 MB partition sitting on your 2GB SD card you retain the existing 250MB filesystem unmodified and then create a second partition that uses the rest of the disk. (Obviously this will mean you end up with two separate drive volumes sitting on your desktop.) The two ways I can think of approaching this would be to:

A: Use a binary editor to attempt to modify the existing disk label on the volume that you DD'ed over from the ZIP disk, modifying the correct field so the MacOS container "looks bigger", and then use a non-destructive disk partitioner to create the second volume (you'll be digging into some arcane documentation to pull this off), or possibly B:

B: Create from scratch a new disk layout by formatting and partitioning it with the requisite native disk tools. (IE, write the disk label and drivers with the Mac formatter, and then create two data volumes; one a tiny bit bigger than your current filesystem and the other occupying the rest.) Then mount the DD-ed-from-the-ZIP SD card and the new SD card you formatted on a computer that understands classic Mac disk labels (I think OS X still does, another option would be Linux), and then DD the contents of *the data partition your copy-protected program is in* over the corresponding section of the new disk. (IE, we're not DD'ing over the full raw disk, just the actual partition data.) I *think* that might legitimately work. (Unless the copy protection for the program does evil things like caring about specifics of the disk label, etc.) Your mileage may totally vary.

Plan B: My vague understanding is that the SCSI2SD can actually emulate multiple SCSI disk devices at once, does that help you? I honestly have no idea, I don't own one.