Mount zip file doesn't work since version 0.83.23 ?

[aetchris]

Describe the bug

Programs mounted in zip files don't launch since after version 0.83.23.

Steps to reproduce the behaviour

Mount a zip file as drive c
Try to launch program
Dosbox-x hangs and program doesn't launch

Expected behavior

In version 0.83.23, the program launches.
After this version, dosbox-x seems to hang up with a black screen

What operating system(s) this bug have occurred on?

Windows 10

What version(s) of DOSBox-X have this bug?

Since 0.83.24

Used configuration

mount C "pathtozipfile\file.zip:\"
C:
cd\
program.exe

Output log

Many "ERROR CPU:Illegal Unhandled Interrupt Called 6" in output

373108514 ERROR CPU:Illegal Unhandled Interrupt Called 6
 373108611 ERROR CPU:Illegal Unhandled Interrupt Called 6
 373108708 ERROR CPU:Illegal Unhandled Interrupt Called 6
 373108805 ERROR CPU:Illegal Unhandled Interrupt Called 6
 373108902 ERROR CPU:Illegal Unhandled Interrupt Called 6
 373108999 ERROR CPU:Illegal Unhandled Interrupt Called 6
 373109096 ERROR CPU:Illegal Unhandled Interrupt Called 6

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[grapeli]

I confirm does not work from the moment of introducing these changes #3347.

[aetchris]

The issue seems to be resolved in version 0.84.1. Thanks a lot!

[grapeli]

I have not noticed any improvement. It still does not work.

keen6.zip
bomber.7z.txt

dosbox-x -c "mount c ./bomber.7z" -c "c:" -c "cd 3dbomber" -c bomb
dosbox-x -c "mount c ./keen6.zip" -c "c:" -c keen6

After undoing these unfortunate code changes #3347, it works.

[aetchris]

Well, that's strange... The issue seems to persist on some programs, and not others... For example, "Elite" in a zip file works, whereas "Elite plus" in a zip file doesn't.

[NebularNerd]

I have the same issue with an old Dynamix title 'Stellar 7' happy to supply zip if needed.

[grapeli]

I am surprised by the long lack of response to reporting this bug from developers.

For those who need this functionality and are able to compile on their own, I suggest undoing these unfortunate changes to the code.
revert-3347-fix-mount-zip.patch.txt

[tbr]

Hi, I'd also like to confirm that this problem persists. An example to trigger this bug is to use (in DosBox-X) "edit somefile.txt" where "somefile.txt" is a file inside a mounted zip file as drive (with an overlay mount on top of it). DosBox-X will hang while spawning the interrupt 6 error on console as described in this issue.

Moreover, I was reviewing merge #3347 and I believe that there is also a mistake made (but I might be wrong): on dos.cpp:line1895 there is now a call to MEM_BlockRead which seems wrong (I think it should be MEM_BlockWrite) as it is the code for 0x3f (File Read) which reads from file (writing) into a memory block.

[NebularNerd]

Looking forward to seeing this fixed, I'm trying to compile the code with @grapeli patch but it's been a while since I did some basic compiling and things are much more complicated now.

The .zip thing has been one of the great things added to DosBox, the ability to enjoy a program or game freely without harm to the original install is ideal for both preserving and running multiple copies of a base install (Say Win 3.1) but with different driver/software combinations as required, any issues occur you can simply delete the overlay directory for that run and start again. With modern systems the speed difference is barely appreciable.

[NebularNerd]

Just seen this was merged last night and tested with build dosbox-x-vsbuild-win64-20220901051309, My copy of Stellar 7 now plays from inside a regular .zip and my stupidly high compressed .7z without issue.

Big thumbs up to @tbr for the fix. 👍😁

[tbr]

While this is now fixed, I'm seeing still some issues when combining ZIP/7Z drive mounts with an overlay folder (for writing changes, like save games). So, more debugging is probably advised.

[NebularNerd]

While this is now fixed, I'm seeing still some issues when combining ZIP/7Z drive mounts with an overlay folder (for writing changes, like save games). So, more debugging is probably advised.

I played tested a few games yesterday all using an overlay and had no issues personally. If I come across one I'll update this reply. I'm sure there will be a couple of games in my collection that access drives in a weird and wonderful manner.

[aetchris]

Seems to work very well! Thanks a lot for the fix. I will test some games to see if i can find issues.

[NebularNerd]

I think I've found another zip related issue. Z by the Bitmap Bros. Installing from an .iso of my own CD and running it from a mounted folder is fine, however the moment you try to run it from a .zip your get file missing errors on load.

I've also tested this using a copy found at Z @ myabandonware it runs just a treat in their browser dosbox version (it unpacks to a directory) and if you download/unpack it to a folder on your own system, however try running their .zip as a mounted drive again gives files errors.

[grapeli]

@NebularNerd
I confirm. Attempting to run this game "Z 1996" directly from the archive fails.
Only the reason is completely different from the one in this original bug report.

Although this is a regression. Works fine to version dosbox-x 0.83.13. The game stopped starting exactly with this code change dc798b5.

edit: After restoring an unnecessarily deleted semicolon from drive_physfs.cpp, the game starts correctly from the archive.

[NebularNerd]

@grapeli

Ok cool, so we need a fix to 'fix' dc798b5

[tbr]

@grapeli @NebularNerd

I believe the line 2883 should state:
case DOS_SEEK_END:mypos = PHYSFS_fileLength(fhandle)-mypos; break;

The semicolon fix was correct (or at least makes sense), but the += needs to be =. The fileseek from end calculates position as "file_length" minus the provided "mypos".

[grapeli]

The semicolon fix was correct (or at least makes sense)...

It was certainly not correct.
Without this semicolon, this game would not start.
Z_DOS_EN.zip

dosbox-x -c "mount c Z_DOS_EN.zip" -c "c:" -c "cd z" -c "z.bat"

After undoing this unfortunate commit dc798b5, starts without error.

[tbr]

@grapeli I tried your Z_DOS_EN.zip with the provided command. On my system, it fails (with or without the unfortunate commit).

[NebularNerd]

Found another couple that have .zip issues (again likely different from the others). From #2577 the two Holiday Hare versions inside Elkjøp (2).zip both produce the same error.

Unpack to a folder, run setup (I used Soundblaster 16 for audio while testing) and both work as they should. Run from the .zip and you get Setup Error: Can't initialize file manager then it will start the game and appear to work just fine.

When you exit the game you may get a Protected Mode Error across the top of the screen is shown where the normal This is not shareware message should be. Seems to happen very rarely.

There is a write overlay set which works as I can save a config file by adjusting the volume via the ingame menu.

[grapeli]

@tbr
I don't know what your cause might be.
I checked with an incorrect commit dc798b5 undone as well as with your patch. In both cases, it runs flawlessly.

[grapeli]

@NebularNerd
It would be ideal if each packed archive in combination with the overlay worked flawlessly. Unfortunately, this is not the case yet.
You have to prepare yourself a properly configured archive of this kind. Is there a bug here? I don't think so.

This version works flawlessly.
Elkjop.3.zip

dosbox-x -c "mount c Elkjop.3.zip" -c "c:" -c "cd JAZZHH94" -c "jazz"

[NebularNerd]

@NebularNerd It would be ideal if each packed archive in combination with the overlay worked flawlessly. Unfortunately, this is not the case yet. You have to prepare yourself a properly configured archive of this kind. Is there a bug here? I don't think so.

This version works flawlessly. Elkjop.3.zip

dosbox-x -c "mount c Elkjop.3.zip" -c "c:" -c "cd JAZZHH94" -c "jazz"

@grapeli
Most strange, that seems to behave the same for me (although setup worked in Elkjøp (2).zip here it just fails totally, mounted just the zip (no overlay) and still sends out the error, then starts the game as before. I'm still on the dosbox-x-vsbuild-win64-20220901051309 if that makes any odds.

I've been playing heavily with .zip mounting (from way back in the early days when it was announced on VOGONS) so I know there is always going to be some weirdness with a pretend filesystem. As you say it would be awesome if everything just worked, but then there would be no fun in it.

[grapeli]

@NebularNerd
You expect too much. The files in the packed archive are read-only.
To be able to use it, you have to go through the configuration stage and repack again. Then you can count that such a prepared and connected archive will work in dosbox-x (of course in many cases it will also be impossible).

You can't really count on using an overlay as this layer is not entirely physfs compatible. I recommend that you read this #3355 bug report carefully.

[NebularNerd]

@NebularNerd You expect too much. The files in the packed archive are read-only. To be able to use it, you have to go through the configuration stage and repack again. Then you can count that such a prepared and connected archive will work in dosbox-x (of course in many cases it will also be impossible).

You can't really count on using an overlay as this layer is not entirely physfs compatible. I recommend that you read this #3355 bug report carefully.

@grapeli
Far from it, I simply copied your command as you printed it to test under the same conditions and found that it produced the issues as posted. I'm fully aware of what you can and cannot do with .zip files. I wish my coding skills were better and I could more actively help debug and submit patches like yourself and @tbr, but beyond some basic stuff I'm no expert, however I'm good at testing/breaking things. 😁

I use the same method to test each game/program. Download & unpack to a folder / Install from images of my original media, setup, test and patch as needed. Once it's all running as it should, repack to a .7z or .zip then run from a bat file with the following script.

%~dp0DOSBox-X\dosbox-x.exe -conf %~dp0DOSBox-X\PLAYGAME.conf -defaultdir %~dp0DOSBox-X -c "mount c %~dpnx1" -c "mount c %~dp0~~write\d-games -t overlay"

This mounts the .zip plus an overlay for write access, test again, if all works, excellent, the game runs from the .zip and saves/additional files live in the overlay. Where it does not I'm mentioning them here where those with the skills to identify the issues may wish to investigate. As @tbr mentioned, some things do not behave as they should even after the recent commit. As we see in the case of Z, another commit lays behind that issue rather than the initial one that this thread was about.

Testing the following using the original files, we see that a change occurred in the code between JAZZ.zip (from #2577) and the later Holiday Hare versions in the Elkjop.zip's that makes them .zip unfriendly. I did not bother running the game in each case, as mentioned further up the jazz.exe's will run and save a config file to the overlay if you tweak the audio volume via the ingame menu, this shows the overlay is setup correctly in all instances, however the setup's in the HH versions produce the errors as shown here and simply do not run. Unlike the Z issue, the jazz.exe's are still playable so it's more of a 'that's weird' rather than a 'it don't work at all'. If you perform the setup then rezip as you state, the game will play with your preferred settings albeit displaying the errors. Personally I will still run from the .zip versions and just ignore the error messages.

JAZZ.zip

Command.003-1.mp4

Elkjop.2.zip

Command.001-1.mp4

Elkjop.3.zip

Command.002-1.mp4

Regarding #3355, while this is true it should not prevent the setup.exe from running. The only issue in the case of using these .zip's 'as is' should be that running setup would either give a write error (with no overlay, although in the case of JAZZ.zip if you delete SOUNDCRD.INF from the .zip then mount without the overlay it simply exits without any error) OR the overlay copy of the file is ignored until the copy inside the .zip is replaced or deleted. Ideally the overlay should take preference as @thesnable has raised in #3355 and here icculus/physfs#18, I have also asked about it in the plans for PhyFS 4.0 here icculus/physfs#41

[grapeli]

@NebularNerd
As mentioned, I undone this commit dc798b5.
For me, setup.exe starts from the Elkjop.3.zip zip archive.

dosbox-x.zip.mount.mp4

[NebularNerd]

@NebularNerd As mentioned, I undone this commit dc798b5. For me, setup.exe starts from the Elkjop.3.zip zip archive.

dosbox-x.zip.mount.mp4

Cool so it's the same bug that prevents Z running inside a .zip, I wonder what else is out there it fixes...

[grapeli]

An identical segmentation fault occurs when trying to run a Barney Splat.
BarneySplat (1993).zip

dosbox-x -c 'mount c "./BarneySplat (1993).zip"' -c "mount c /tmp/dos -t overlay" -c "c:" -c "cd barneysp" -c ansi -c "@autotype -w .4 -p .2 w , enter , 2 , 4 , enter , enter , enter , enter" -c bs

backtrace.log

[grapeli]

@NebularNerd
Another case that doesn't work properly due to a change in the dc798b5 code. After the semicolon is restored, it works fine.

Circuit Racer (1997).zip
dosbox-x -c 'mount c "./Circuit Racer (1997).zip"' -c "c:" -c "cd cirracer" -c "cr -novbl"

I suspect that there may be many more such "cases".

edit:
Next "case" found.

Claas - Der Erntespezialist (1996).zip
dosbox-x -c 'mount c "./Claas - Der Erntespezialist (1996).zip"' -c "c:" -c "cd claasder" -c "claas.bat"

[NebularNerd]

Can confirm the Circuit Racer and Claas behave as above.

Where do I need to look for the seg faults? Also BarneySplat is a very disturbed 'text adventure'

Found one that refuses to play even with the patches, cyberboxdlx.tar.gz from #3090. Unpacked it runs fine, repacked into a .zip, it complains about CURSR-01.DAT missing and bombs out to the dos prompt.

[grapeli]

Where do I need to look for the seg faults? Also BarneySplat is a very disturbed 'text adventure'

For me, it follows this command that I pasted. Only the first time writing to the overlay directory. Not the next time you run it. Without the fix on mount overlay does not occur. Although she herself does not seem to have any influence on it.

Found one that refuses to play even with the patches, cyberboxdlx.tar.gz from #3090. Unpacked it runs fine, repacked into a .zip, it complains about CURSR-01.DAT missing and bombs out to the dos prompt.

I can confirm.
edit: At startup it tries to change (set) attributes on several files (maybe mount overlay can't do that).

[NebularNerd]

I tried placing the CURSR-01.DAT in the overlay to see if that would do it and no luck, tried removing it from the zip just to doubly make sure and still no luck. Whatever it's doing it's doing it in a weird way.

[grapeli]

@NebularNerd
Unfortunately, the cyberbox does not work when used with mount zip.

This program runs without any problems if you mount the directory with this game in read-only mode and use the overlay mount additionally. Then the attributes of the files in the overlay directory are properly changed.

.DBOVERLAY_ATR_BOXES-01.DAT 
.DBOVERLAY_ATR_CA-CYBER.CFG
.DBOVERLAY_ATR_CA-CYBER.TXT
.DBOVERLAY_ATR_CURSR-01.DAT
.DBOVERLAY_ATR_V-EDC-01.DAT
.DBOVERLAY_ATR_V-EDC-01.SOL
BOXES-01.DAT 
CA-CYBER.CFG
CA-CYBER.TXT
CURSR-01.DAT
V-EDC-01.DAT

The game starts.
I tested it like this.
systemd-run -G --user -p PrivateUsers=true -p BindReadOnlyPaths="/tmp/test/cyber:/tmp/cyber" ./dosbox-x -defaultdir /tmp/dosbox-x/src

dosbox-x.cyberbox.mount.overlay.mp4

[NebularNerd]

Interesting, so that would point to PhyFS being the issue as it works with your test. I copied your method to test WordPerfect 5.0 as that has some weird issues where you cannot save a file when inside a .zip and it produces similar results. Inside a .zip it starts writing a mix of files when you try to save a document but you just get write errors. With your method the file saves just fine.

[grapeli]

Interesting, so that would point to PhyFS being the issue as it works with your test.

Exactly.
You can do this test yourself.
The mounted directory from Cyberbox must be read-only. More you can't change the file permissions on it. Most conveniently, if the owner of this directory with files is another user (even the administrator), you will only have read access.

[grapeli]

DOOM 2D is a very interesting case.
DOOM 2D (1996).zip

Well, straight from the zip archive it does not start (also with overlay). Even if it started correctly, it would be dramatically slow that this way of starting it is disqualifying. When loading the DOOM2D.WAD file, it takes about 60 seconds in my case, the whole CPU load is generated by tinfl_decompress from src/libs/physfs/physfs_miniz.h.
Then all sorts of things happen. After 5 minutes, I usually stopped.
Sometimes.

Sometimes dosbox-x exits with a message - E_Exit: IRET:Illegal descriptor type 0.

Surprisingly, with the 7z (lzma2) archive, doom2d boots up and it runs quite smoothly.
DOOM 2D (1996).7z.txt

Unpacked and mounted directory in read-only mode does not start.

With the help of an additional overlay directory - starts up.

[NebularNerd]

The .zip copy really has some weird performance issues, I tried using dos32a doom2d.exe and that got the game running everytime against the sporadic loading without (still slow). It throws up an error after you exit but it runs...

*This happens on the .7z copy as well. *

I also tried repacking the .zip to see if that would help but still the same fault, repacking to .7z (even my crazy solid archive setting) does cure the issue. I also managed to figure the setup options and set to Soundblaster from Adlib, just need to figure out the keys bindings as I can't seem to trigger the door switches.

I tested with my own test build and the new autobuild from my PR #3723 (64bit Visual Studio)

EDIT
This is not just an issue with DOOM-2D, other games perform differently depending on where they are. The XCar Demo mentioned in #1285 runs fine in a regular .zip, but hates being in a heavily compressed solid .7z despite only being 6mb in size it more or less locks up after a slow load to the title screen.

[grapeli]

I tested with my own test build and the new autobuild from my PR #3723 (64bit Visual Studio)

I added them permanently five days ago. They remove faults without generating new ones.

edit: I will summarize the discussion about the semicolon like this. I am not a programmer. You have to move from theory to practice. Test these four examples:
Z_DOS_EN.zip
Elkjop.2.zip
Circuit Racer 1997.zip
Claas - Der Erntespezialist 1996.zip
and draw the correct conclusions.
Without testing, you can be wrong.

The probable reason for removing this semicolon was a warning during compilation, and only it.

drive_physfs.cpp:746:57: warning: statement has no effect [-Wunused-value]
  746 |  case DOS_SEEK_END:mypos += PHYSFS_fileLength(fhandle);-mypos; break;
      |                                                        ^~~~~~

It is possible that even tests have not been performed.

[NebularNerd]

@joncampbell123 looked into the code and found the whole ; -mypos was redundant and has updated and merged my PR to remove it. Removing the ; broke things because it was trying to perform unwanted maths (PHYSFS_fileLength(fhandle)-mypos). adding the ; 'fixed' it by essentially causing -mypos to be skipped over as an invalid command/instruction.

The new versions moving forward will have both the ; fix and the overlay fix that we have both (rather extensively) tested. 😁

[tbr]

Has anyone tried my suggested change to the famous line with the ";"?

I believe the line should state: case DOS_SEEK_END:mypos = PHYSFS_fileLength(fhandle)-mypos; break;

This actually contains two changes: 1) the ; removed and 2) the += is changed to =. The reason I believe this is correct is that DOS_SEEK_END is the int 21h functionality to seek an offset in a file, starting at the end (instead of current position or beginning of file).

There is also a reason why putting back the ; in the line makes some programs work. In that case, PHYSFS_fileLength(fhandle) gets added to mypos, and a few lines later the mypos is clipped to maximum PHYSFS_fileLength(fhandle). This means that for any DOS program using this DOS_SEEK_END with offset 0, the file pointer will be set at the end of the file (just as requested). However, if offset is too large, it will not end up at the correct position.

If fixing this line still makes certain programs fail, then there is another place in the code that is bugged.

[grapeli]

I believe the line should state: case DOS_SEEK_END:mypos = PHYSFS_fileLength(fhandle)-mypos; break;

Then this program does not start.
dosbox-x -c 'mount c "/tmp/Claas - Der Erntespezialist (1996).zip"' -c "c:" -c "cd claasder" -c "claas.bat"

[NebularNerd]

Has anyone tried my suggested change to the famous line with the ";"?

I believe the line should state: case DOS_SEEK_END:mypos = PHYSFS_fileLength(fhandle)-mypos; break;

@tbr
I did try it further up when I made my first builds, it does not break anything but equally did not improve things, once you ditch -mypos things improve greatly, as @grapeli mentions here -mypos prevents these all from working. I did try a few combinations with += and = along with and without ;, but it's now pretty clear that losing ; -mypos is the way to go. The PhyFS author suggested dropping the -mypos as well when I tagged him in this thread.

I might run up a build with = (but no mypos) and see how it behaves on some fringe cases that are still being weird, but those seems to be ones such as Cyberbox and Word Perfect 5.0 that want to muck with file attrib's or somesuch. I've been working through games listed in various old issues and using them to test .zip behaviour and post-fix all seem to be working for me.

You mentioned you had some games that were still misbehaving after your PR, were they from the lack of overlay files taking preference over .zip contents (which they now will) or something else?

[maron2000]

@tbr If you are to change += to = then you must delete -mypos.

[NebularNerd]

Found another while testing games in #2377, Fallout runs fine outside a .zip but once compressed suffers initially very slow loading and then more of less a total lockup when you try to enter the game or load a save. This is the same for a lightly compressed .zip or my ridiculous solid .7z archives.

I imagine the 500mb+ zip with two large .dat files (one about 100mb and the other 300mb+) is the issue in this case 🤣

My personal solution to this would be to unpack the game to my Ram drive, mount the unpacked folder read only, use my regular overlay folder and play that way.

[grapeli]

Well. I have mixed observations regarding the built-in support for mounting ZIP/7Z archives as drives. Is it useful? To a limited extent, yes - small or very small archives, without the need to attach floppy disk images, CDs. The built-in dosbox-x overlay doesn't always work well with the mount zip. Sometimes it is completely impossible to run the software from such a mounted archive. Poor compression with zip. Very slow decompression (with physfs).

Are there better solutions. There are a lot of possibilities under linux.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/squashfs.rst
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.rst
https://github.com/plougher/squashfs-tools/blob/master/USAGE
The best in my opinion is Squashfs + Overlay Filesystem (not the dosbox one). Benefits:
-absolutely everything works, including direct mounting of CD images without completely decompressing,
-much better compression - xz as in the case of zstd (compared to zip),
-very fast decompression (especially Zstd, zip).

Other solutions.
https://bitbucket.org/agalanin/fuse-zip
https://github.com/google/mount-zip
https://github.com/google/fuse-archive

[grapeli]

Fuse-zip can be used writable (no need for overlay fs, either linux or dosbox-x).

Although with compressed large CD images, this solution may be too slow (even useless). Squashfs does not have this drawback. There, access to data is incredibly fast. Especially with zstd compression.

[NebularNerd]

I agree, I think PHYSFS is still a great bit of code but as you point out it does have limitations. Looking at a recent pull #3776 it's obvious that fixing things relating to PHYFS likely breaks other things. Maybe in the future when/if a later version of PHYSFS is brought into play some of these issues will be fixed.

I enjoy having the ability for games to run from a tidy single file that also keeps my working installs safe and sound. However, I think moving forward I will still use it for some titles, but for larger or tempramental games such as ones we have come across here I'll switch to my other method rather than trying to keep bludgeoning PHYSFS into behaving.

Squashfs is certainly an interesting choice, given how well you can run a kernel out of it, a prehistoric game would likely be just fine. Minor downer would be the lack of plug'n'play due to not being able to mount a .zip directly (not an issue for power users just need a script to do zip->squashfs or similar).

Any zip based solution such as FUSE will likely suffer similar performance issues due to the whole .zip thing. Also I'm not sure about the writing back to a live .zip, I would worry about something glitching due to a wonky cycles and the whole .zip getting trashed. Overlays are far safer as you can always roll back to the working copy.

[grapeli]

Of course, dosbox-x's built-in solution also has advantages. Simplicity.
Although for some, understanding the idea of resource mounting is a big barrier. Especially at the beginning.

This solution based on Squashfs + Overlay Filesystem (Linux) is intended for very advanced users.
To do from the normal user position is even more difficult.
You have to use squashfuse.

Overlayfs as a normal user can only be mounted with user namespace (from kernel 5.11).
However, it's best to use fuse-overlayfs (this also works with much older kernels).
unshare --mount --user --map-root-user sh -c "fuse-overlayfs -o lowerdir=/tmp/a,upperdir=/tmp/c,workdir=/tmp/w /tmp/c ; mount ; ls -l /tmp/c ; fusermount -u /tmp/c"

[NebularNerd]

And of course we would need a Windows friendly version of all this 🙂 Macs and Android users would in theory be able to all play with your example.

[grapeli]

Sample one liner ready.
unshare --mount --user --map-root-user sh -c "squashfuse './Terminal Velocity 1995.sqf' ./sqf ; fuse-overlayfs -o lowerdir=./sqf,upperdir=./dos,workdir=./w ./dos ; dosbox-x -set memsize=34 -set cycles=max -c 'mount c ./dos' -c 'imgmount d ./sqf/TermVel/cd/Term.bin -t cdrom' -c 'c:' -c 'cd TermVel' -c 'cd tv' -c 'tv' 2>/dev/null ; fusermount -u ./dos ; fusermount -u ./sqf"

edit:
One more remark. fuse-overlayfs is 100% effective. Dosbox-x overlay may not work in some cases. It's hard to give a specific number, let's assume it's 3%. So quite a little and in a very large amount it may be sufficient. In many cases, the entire procedure can be simplified considerably by resigning from the need to use user namespace (unshare).

Simplified version.
squashfuse './Terminal Velocity 1995.sqf' ./sqf ; dosbox-x -set memsize=34 -set cycles=max -c 'mount c ./dos' -c 'mount -c ./dos -t overlay' -c 'imgmount d ./sqf/TermVel/cd/Term.bin -t cdrom' -c 'c:' -c 'cd TermVel' -c 'cd tv' -c 'tv' 2>/dev/null ; fusermount -u ./sqf

This has another plus. Under DOS, many files are opened for writing, but absolutely no changes are made to them. The launched game can, for example, open 16 such files with a size of 500kB, then the dosbox overlay will ignore them, contrary to fuse-overlayfs (it's not his fault), which will add them and leave us unnecessarily taking up about 8MB of space on the medium.

[NebularNerd]

Ah the joys of PHYFS, it appears that post #3776 zip performance has plummeted, I have a beefy machine and zip access on small .zips (100mb or under) was near instantaneous, now there are huge pauses just to get a dir.

I think this seals it for me, PHYFS in the bin, I'm going back to my old school method of unpacking to a ram drive, mount as -ro and use an overlay there. My python file automates this for me so it's no more inconvenient than mounting the .zip, just a few extra seconds on startup to unpack the archive first.

[grapeli]

@NebularNerd
A very simple test. I measured the time it took to start the game Z 1996 mentioned above (new game, and after loading level 1, exit dosbox-x immediately).

type	time in seconds	size in bytes
no compression	15	21639943
squashfs zstd	15	10170368
squashfs xz	17	9711616
fuse-zip	18	11711277
physfs zip	26	11711277

The original zip archive file, I shrunk with advancecomp (zopfli).

I haven't tested this recent code change, but I don't think it has any significant performance impact.

[icculus]

Having not looked at this further, I suspect PhysicsFS is being used without buffering enabled.

https://github.com/icculus/physfs/blob/fdd38a3f8a1ca4cb9e0d491a1b1f3c73595ac020/src/physfs.h#L1465-L1505

[NebularNerd]

Hi @icculus, we'll take a look and see if that helps. Some of the issues are coming from PhysicsFS not being the only file system in town, there are some issues in the source where it has to share with others, someone may fix something which may partial break something else, for example in #3776 a bug that was fixed in relation to PHYSFS breaks something in the regular file handling so had to be undone.

@grapeli
I noticed that most with a recent compile that .zip games started dragging their heels, longer loading times and strange hesitations, yet my personal compile I made when testing the initial overlay fix loads them as expected and much faster. I'll have a look at the buffering but I may not spend huge amounts of time on it. I can unpack a solid .7z to ram quickly enough and get near enough instant loading of anything (emulation/software/overlay contents permitting).