Failure to locate subfolders with complex names in DOS

[andyherbert]

(Originally named: "Opening a read-only folder within DOSBox")

I'm not sure if this is a limitation by design by the underlying architecture, or an actual bug, but attempting to drag and drop a read-only folder, or opening an associated read-only file silently fails when launching Boxer.app.

I'm assuming that Boxer.app expects read & write privileges when mounting a hard drive, but I've been caught-out by the application when trying to mount a volume in Boxer by dragging a folder which is itself mounted in OS X from an iso image.

[alinebee]

This would be a bug, not a limitation: Boxer normally handles read-only files just fine, likewise with read-only volumes and their OS X mount points. What different folders or images have you tested this with, and what version of Boxer are you using?

I suspect the read-onlyness is a red herring here and the problem is more file- or volume-specific: for instance, if an ISO is readable by Finder but not by Boxer's DOS-level image support, then it may fail to mount in Boxer despite appearing to be a normal folder when opened in Finder. (It's the same whether you mount the folder or the image itself: when you try to mount a folder that's backed by a disk image, Boxer will try to mount the image instead to provide more accurate emulation.)

Also, there are different kinds of read-onlyness in OS X: There's files that are located on a read-only volume, like a CD or an ISO, then there's files on a read-write volume whose file permissions resolve as read-only for the current user. Could you test the latter by creating a folder on your desktop, marking the folder as read-only for the "Me" user in Finder's Get Info window, then dragging it into Boxer? (And if that fails, does it work if you switch back to read-write access on the folder?)

[andyherbert]

You're quite right, it doesn't appear to be due to the read-only attribute, and I confirmed this by doing what you suggested and manually marking the folder as read-only after copying the folder to my desktop. Here's what I've discovered:

I'm using Boxer Version 1.3.2 | build 20120713.1, and the iso available at ftp://ftp.untergrund.net/users/taat/taat/files/the_complete_tmdc.zip which is an .iso containing demoscene entries linked from http://taat.fi/taat/ (search for 'TMDC' or 'Text Mode Demo Compo').

After opening the iso in OS X, the volume is available at /Volumes/Complete\ TMDC/tmdc/, dragging tmdc/tmdc1/00.Invitation/ to the Boxer.app icon drops me to the Z: prompt. However, by typing:

mount c "/Volumes/Complete TMDC/tmdc/tmdc1/00.Invitation"

Boxer succesfully mounts the drive. So, I'm still not sure why the folder isn't mounting in Boxer, but I'm now certain now that it isn't because of the read/write status.

[alinebee]

OK, so after testing with this ISO here's what I've found:

When you drag the 00.Invitation folder into Boxer, the drive is actually mounting correctly. However, Boxer 1.3.2 is failing to switch to the intended drive and directory afterward, so the prompt remains on drive Z. This is happening because Boxer 1.3.2 cannot resolve a proper DOS path to the 00.Invitation folder, which is a bug.

Note that Boxer's behaviour here is not quite what you think. If you drag a regular folder into the DOS window, Boxer mounts that folder itself as a new hard drive. But if you drag in a folder that's on a CD-ROM volume, Boxer mounts the volume as a new CD drive, then determines the DOS path for the folder you dropped in, then changes the working directory to that.

This is also what happens if you drag in a folder located on an existing drive: Boxer looks up the path and switches to the folder, instead of mounting a new drive from it. The action of dragging a folder into Boxer doesn't strictly mean "make a new drive out of this" but rather "make this location available in DOS, the best way you know how."

In practice, Boxer 1.3.2 isn't very good at determining DOS paths to subfolders of a mounted drive. This has been improved since, so that Boxer 2.0alpha (the current development version) is much better at this, but even that's still choking when resolving the "00.Invitation" name - the dot in the middle of the name may be throwing things off. So there appear to be bugs remaining in Boxer's DOS path resolving that I'll need to look into.

I've updated the title of this issue report to better reflect the actual problem, and I'll keep the issue open until I've fixed the underlying bug(s).

In the meantime: you can mount an individual folder off the CD with the Drives->Add DOS Drive... menu option, which gives you a lot more control over how Boxer mounts the drive: e.g. you can choose the drive letter and type, and it'll mount the exact folder you point it at. This is akin to the DOSBox mount command, and will sidestep the whole path resolution issue altogether (since the funkily-named folder is the root of the drive.)

[andyherbert]

Ah, that makes more sense. I did notice that the iso was automatically mounted as an isoDrive on D, but for some reason my expectation was still pointing towards the folder being mounted as C, instead of changing the path to the already-mounted device. But you explanation makes more more sense to me now.

[alinebee]

Ah yeah, Boxer automatically detects and mounts all CD and floppy-disk volumes that are currently mounted in OSX, without you needing to mount them manually: so it would only be doing the latter part of the process (resolve DOS path to folder and change working directory), with the same end result.

(It looks like the demos in that ISO really don't care about the fact that they're on a CD - the collection could just as well have been distributed as folders in a simple zip file. Boxer's CD-handling behaviour is designed for discs that contain a single game, and isn't very suitable for collections of many games/demos/applications.)

[alinebee]

Well, 8375da1f70e91bf31f158904762fe2ef15538781 has fixed one major bug with complex filenames. Boxer normally tries to look up the computed DOS 8.3 filename from DOSBox's own filesystem cache, but it turns out I had broken this lookup a while ago so it was failing to resolve any long filenames. That commit restores it to its proper working order.

However, another more difficult limitation remains with long filenames on CD images. In these cases, DOSBox does not generate its own shortened filename for Boxer to look up: instead it uses the shortened filename stored in the CD's own ISO9660 filesystem (as opposed to OSX, which will see the longer filename from the CD's entirely separate Joliet filesystem.)

Resolving Joliet filenames to ISO9660 filenames is something Boxer could only authoritatively do by inspecting both of the CD's own filesystems, which would involve writing a whole lot of Joliet parser code. Approximations could be made by comparing the OS X directory list to DOSBox's and picking out entries that look like they correspond, but that has hard edge cases.

Working on a solution to this limitation doesn't feel particularly worthwhile because DOS games never used long filenames and DOS CDs didn't use the Joliet filesystem: hence this limitation only really comes up with handmade compilation ISOs like the one mentioned in this issue. Hence, I'm flagging this issue as closed-for-now.