Recursively mounting .tzst archives fails

[FalsePhilosopher]

Attached is a log of trying to recursively mount a .tzst archive, a -v output(1.2.2 appimage), and a -d 3 output.
log.txt

[mxmlnkn]

What exactly does not work? I see segfaults in your first tries, which are self-explanatory. I am surprised that your log only shows the segmentation fault for the first tries. The verbose and -d 3 ones seem to fail because the target mount point cannot be used, probably because the segfaulted tries did not properly clean up the mount points. Try fusermount -u <mount-point> to fix this. The automatically chosen mount point is simply the name of the archive without the .tzst extension. It would be nice if I had a file to reproduce your issue.

Does the last AppImage work for you? Does the nightly AppImage work for you? In both, I have tried to pin indexed_zstd to < 1.7.0.

In order to fix this, a reproducer file and/or a backtrace of the segfaults in your first tries would be very helpful. Backtracing the AppImage might be slightly hard to do. It could work with this:

ratarmount-*.AppImage --appimage-extract
sed -i 's|exec "$APPIMAGE_COMMAND|gdb -ex r -ex bt --args "$APPIMAGE_COMMAND|' squashfs-root/AppRun
squashfs-root/AppRun -f silesia.tar.gz mounted

Is it actually a Zstandard-backend issue? If possible, could you recompress the tzstd into something else to check whether it works with a different, or no, compression at all? The backtrace might already answer that question.

Do you need recursive mounting? It seems that it tries to mount pywintypes.lib, which might not be what you want anyway. I need to work on a better recursive mounting filter to avoid that. If you have the above extracted AppImage, you could disable it by removing it from the FID.AR extensions in squashfs-root/opt/python3.14/lib/python3.14/site-packages/ratarmountcore/formats.py. The failure to python312.zip looks very weird; it might be a bug in ratarmount.

[FalsePhilosopher]

What exactly doesn't work? It doesn't mount the archive, instead throws the segfault and nothing happens. I tried with the last appimage and it gives the same error, I tried with the nightly and it threw a lot more errors. Here is a log of that as well log.txt . I tried nested tar's without any compression and got similar errors. It seems to be an edge case with this games files containing different archive types. Mounting nested zstd compressed tars works fine, it just doesn't seem to handle multiple types in multiple layers which sounds like a nightmare to get it working straight. I resolved this issue by just setting the mount depth to 2, so this can be closed. If you really feel like chasing this edge case I grabbed the initial archive from steamrip.

[mxmlnkn]

Thank you for trying so much to get to the bottom of it. The errors with the nightly look expected and unexpected at the same time. The missing recursive mounting file extension list control and some more conservative default for that is what keeps me from the next minor release. It tries to mount the html files. However, the errors that are shown because of that are unexpected. Well, I'll keep this open for now, hoping that I might get to try around a bit more on the weekend.