Unable to open some CD-ROM disk images containing HFS partitions

[gingerbeardman]

from: https://sourceforge.net/p/catacombae/bugs/5/ apologies for posting in the wrong place and having two issues in the one thread.

I have some old HFS CD-ROM that cannot be opened.

In HFSExplorer: the Partition map is found:

then after pressing OK I get "could not open file".

Here is a link to one, though I have many more CD-ROMs that are like this: https://archive.org/details/maclife-kanjitalk-75

It also happens with CD-ROM without any strange encoding in the partition/volume names.

Since Catalina macOS is no longer able to open these old HFS CD-ROM so my current workaround is to mount them in an emulator (BasiliskII) to work with them, which is cumbersome. Of course I use HFSExplorer for some other HFS CD-ROM.

(They also have Japanese encoding but a fix for that is in the proposed branch)

• Screenshot 1: shows directory structure as mounted in System 7

• Screenshot 2: shows ISO Buster listing the HFS partition

ISO details:

MACLIFE-KT75.ISO: Apple Driver Map, blocksize 512, blockcount 660064, devtype 0, devid 0, driver count 0, contains[@0x200]: Apple Partition Map, map block count 2, start block 1, block count 2, name Aplix CDWriter/DiscManager 1.00, type Apple_partition_map, valid, allocated, readable, contains[@0x400]: Apple Partition Map, map block count 2, start block 64, block count 660000, name MACLIFE 1995?N1????, type Apple_HFS, valid, allocated, readable

Debug log below...

Trying to detect CEncryptedEncoding structure...
CEncryptedEncoding structure not found. Proceeding...
Detecting sparseimage structure...
Trying to detect UDIF structure...
UDIF structure not found. Proceeding...
Could not open file! Exception thrown:
java.lang.RuntimeException: length undefined and offset != 0 (fsLength=0 fsOffset=32768)
    at org.catacombae.hfsexplorer.FileSystemBrowserWindow.loadFS(FileSystemBrowserWindow.java:1084)
    at org.catacombae.hfsexplorer.FileSystemBrowserWindow.loadFSWithUDIFAutodetect(FileSystemBrowserWindow.java:880)
    at org.catacombae.hfsexplorer.FileSystemBrowserWindow.loadFSWithUDIFAutodetect(FileSystemBrowserWindow.java:735)
    at org.catacombae.hfsexplorer.FileSystemBrowserWindow$4.actionPerformed(FileSystemBrowserWindow.java:312)
    at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
    at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
    at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
    at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
    at javax.swing.AbstractButton.doClick(Unknown Source)
    at javax.swing.AbstractButton.doClick(Unknown Source)
    at javax.swing.plaf.basic.BasicMenuItemUI$Actions.actionPerformed(Unknown Source)
    at javax.swing.SwingUtilities.notifyAction(Unknown Source)
    at javax.swing.JComponent.processKeyBinding(Unknown Source)
    at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(Unknown Source)
    at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(Unknown Source)
    at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(Unknown Source)
    at javax.swing.JMenuBar.processKeyBinding(Unknown Source)
    at javax.swing.KeyboardManager.fireBinding(Unknown Source)
    at javax.swing.KeyboardManager.fireKeyboardAction(Unknown Source)
    at javax.swing.JComponent.processKeyBindingsForAllComponents(Unknown Source)
    at javax.swing.JComponent.processKeyBindings(Unknown Source)
    at javax.swing.JComponent.processKeyEvent(Unknown Source)
    at java.awt.Component.processEvent(Unknown Source)
    at java.awt.Container.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$500(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue$4.run(Unknown Source)
    at java.awt.EventQueue$4.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

[unsound]

Thanks for moving this thread to github. I'm considering closing down the sourceforge forum anyway since github is a better platform.

I could reproduce the problem with the MACLIFE-KT75.ISO image, and I just pushed a fix to the 'proposed' branch. It was an issue with Apple Partition Map partition parsing which I haven't seen before.

Let me know if that fixes the issue for the remaining images or if there's more work to do. :)

[gingerbeardman]

I'll be happy to take a look, but not sure when I will be able to figure out how to build from source.

[gingerbeardman]

I just needed ant, so now I have built from source with the proposed branch.

The problematic CD-ROM ISOs now open fine. 🎉

I'll test all my remaining ISOs soon.

But I'm still not seeing Japanese text as fixed in https://sourceforge.net/p/catacombae/bugs/5/ ?

[gingerbeardman]

Oh! Silly me. I need to manually select the encoding.

It would be great if this was automatic in some way?

Even just the ability to set Japanese as my default encoding would be fine.

[unsound]

Unfortunately HFS does not specify the encoding used on a volume (as far as I know at least) so selecting encoding automatically is tricky. One would have to scan the volume for filenames and use some heuristic way to figure out the most likely encoding. I don't know of a good way to do that at the moment so maybe an alternative approach would be to use the user's locale to select a default, e.g. MacJapanese if the locale is Japanese?

[gingerbeardman]

That's a reasonable suggestion but it would not help me as I hardly ever run as Japanese locale. It's not so bad as I only need to set Japanese encoding for the first disk and the preference persists across any further disks I open.

One more problematic CD-ROM ISO: https://archive.org/details/info-mac-may-1993-japanese

ISO Buster shows:

BasiliskII mounts it OK. file just shows contents as "data" so even that does not recognise the disk type. Not found any other apps that will mount/recognise it.

[unsound]

I just looked through old Mac OS X code and it does indeed look like the mount utility reads the user's locale and determines the HFS encoding based on that. So I don't think HFSExplorer can do any better unless we start storing preferences which I have avoided so far but since there is in fact a standard Java preferences API we could maybe consider using it to persist the default encoding setting.

Also: I'm currently downloading that problematic ISO, will check it when I have time.

[unsound]

I pushed another patch to allow parsing Apple Partition Map layouts with a broken Driver Descriptor Record (this was the case for INFO-MAC-MAY-1993-Japanese.iso). Apparently this is considered acceptable since macOS doesn't complain when attaching such an ISO (512 byte sector size is probably implied then).

I'm hoping this doesn't lead to any regressions... there are so many quirks and weird cases with Apple Partition Map layouts and changing one aspect of partition system detection may impact another.

The only thing that remains is to refine the encoding selection somewhat.

[unsound]

I have now pushed an update saving the user's selection of HFS encoding and restoring it the next time the application is launched. Let me know how that works out for you @gingerbeardman.

[gingerbeardman]

Excellent! I'll continue to test disks but closing this one as done.

Thank you