mirror of
https://github.com/SabreTools/BinaryObjectScanner.git
synced 2026-02-04 05:35:49 +00:00
"Test" hangs scanning DVD-ROM mounted as UDF #164
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @JohnVeness on GitHub (Jan 5, 2024).
Originally assigned to: @mnadareski, @Deterous on GitHub.
I have a DVD-ROM, http://redump.org/disc/32401/, which is a dual PC/Mac release. It has two filesystems on it, ISO9660 and UDF. I am using Linux (openSUSE Tumbleweed).
If I mount the disc as UDF (which is the default in Linux), and try running "Test" on the folder, it will print "0%" and get no further (the CPU usage goes to 100%). I tried "Test -d" in hope, but no extra text was output.
If I mount the disc as ISO9660, Test works OK. But as mounting as UDF is the default (e.g. happens when insert the disc and click to mount it), it would be nice to get Test working on UDF too.
I notice that the filenames are different in the two filesystems, for example, a file called "Archive.pax.gz" in UDF is called "archivepax.gz" (so, lowercase and only one dot) in ISO9660, if that's any hint to the problem.
@mnadareski commented on GitHub (Jan 6, 2024):
Can you please share the full commandline that you are using? It may give some indicators as to what could be going on.
@JohnVeness commented on GitHub (Jan 6, 2024):
It depends where the disc mounts, but for example
Test /run/media/john/FM2012or (with no difference)Test -d /run/media/john/FM2012. In either case, if the disc is mounted as UDF (default), the output is just0.00%: -and the program never exits.@Deterous commented on GitHub (Jan 16, 2024):
Successfully managed to replicate this problem in WSL as well by mounting a UDF .ISO in Windows, then running Test within WSL
@Deterous commented on GitHub (Jan 16, 2024):
Ah, no. It just took longer to run under WSL and did eventually complete. I was testing with another ISO9660/UDF dual filesystem disc.
Perhaps I cannot replicate it due to how I am mounting the ISO? I assume you have only tested this with a physical drive attached to a nix box?
@JohnVeness commented on GitHub (Jan 16, 2024):
I've tested and see the problem both with a physical drive in a Linux PC, and with the same disc dumped with redumper and mounted like:
I don't actually need the "-t udf" there as it will autodetect and mount it like that by default. Putting "-t iso9660" allows Test to work. But I don't think that's the correct workaround, as there could be files that only show up in the UDF filesystem and so wouldn't get scanned in ISO9660 mode.
@Deterous commented on GitHub (Jan 16, 2024):
I have just tried that exact command in WSL and
Testproceeds just fine.So, it must either be an issue with that specific disc/ISO (more likely), or your specific Linux/hardware setup (less likely)
@Deterous commented on GitHub (Jan 17, 2024):
@JohnVeness could you please try run
ls /run/media/john/FM2012when the disc is mounted?I suspect it will say permission denied. I think BOS is failing to enumerate the directories due to this permission issue.
I also suspect that when mounting
-t iso9660,lswill read the files just fine.Your disc actually has 4 "filesystems": ISO9660, Joliet, UDF, HFS
@Deterous commented on GitHub (Jan 17, 2024):
I printed some info about the ISO:
Which suggests there is a Rock Ridge extension as well.
So, this issue may be caused by this specific disc having a bad rock ridge entry, or the rock ridge entry has blocked read permissinos for whatever reason. Here's the output from
xorrisoI tried mounting the ISO with
-o norockbut getting an error. @JohnVeness could you mount the physical CD with-o norock?If that doesn't help, it seems like this issue is disc-specific, and the best we can do is figure out what's causing BOS to hang when it reaches permission issues.
@JohnVeness commented on GitHub (Jan 17, 2024):
Thanks for your investigations so far.
All things below have been checked with the physical disc and with the dumped image with no difference. I'll show the commands with the ISO for clarity. I added
-o ropurely to remove the read-only warning. I'm running in a root shell (sudo -s) - I should have mentioned that before!Apologies for the length but I thought it best to show all the output. I've split this into multiple comments.
@JohnVeness commented on GitHub (Jan 17, 2024):
@JohnVeness commented on GitHub (Jan 17, 2024):
@JohnVeness commented on GitHub (Jan 17, 2024):
I didn't continue after that as the ISO wasn't mounted.
@JohnVeness commented on GitHub (Jan 17, 2024):
In summary, it seems that when mounted as iso9660 the filenames are lowercase and only contain one "." (e.g. "archivepax.gz"), and contain I/O errors on symbolic links. Nonetheless, "Test" scans the folder OK.
When mounted as udf, the filenames are mixed case and can contain multiple "." (e.g. "Archive.pax.gz"), no I/O errors in ls, but Test doesn't scan the folder.
When mounted as iso9660 with norock, the filenames are mixed case and can contain multiple "." (e.g. "Archive.pax.gz"), no I/O errors in ls, and Test works fine.
And I can't seem to mount as udf with norock.
So, it would seem mounting as iso9660 with norock gives the best output, but still, it would be good to work out why it hangs with the default mount options.
Alternatively, it would be great if BOS could scan the ISO or the ODD block device directly, interpreting the filesystems itself (like it can with ZIP and other container formats), so it wouldn't have to be mounted at all!
Thanks again for your help so far.
@Deterous commented on GitHub (Jan 17, 2024):
Sorry if I missed it - did you try
lswhen you mount the disc as you did before, with-t udfand without-o norock?@JohnVeness commented on GitHub (Jan 17, 2024):
Yep, https://github.com/SabreTools/BinaryObjectScanner/issues/276#issuecomment-1895643399 . Funnily enough there are no error messages for ls with that, yet Test fails. When mounting as iso9660 there are error messages with ls, yet Test succeeds!
@Deterous commented on GitHub (Jan 17, 2024):
Ah, I see. Could you repeat
lswith just the-t udfwithout norock, when not in a root shell?Obviously, BOS is not run with elevated permissions (I should hope not)
@Deterous commented on GitHub (Jan 17, 2024):
I still think it to be a permissions issue, but I could be wrong and the Unicode naming may be the issue. In either case, I have narrowed it down to getting stuck when dotnet is enumerating files, so this may not be something that we can solve (limitation of dotnet).
@JohnVeness commented on GitHub (Jan 17, 2024):
You're right that I shouldn't run BOS in a root shell... but I was!
Otherwise I have to sudo mount with
-o ro,nosuid,nodev,relatime,uid=1000,gid=1000so I can read the mounted folder as non-root, and I'm lazy!So no, it's not a permissions issue.
@Deterous commented on GitHub (Jan 17, 2024):
Ok, I have retested with it mounted as you did, and it still "hangs" when running
Directory.EnumerateFilesUsing
.GetFilesdid not solve the issue. I'm unsure why dotnet is behaving this way but it doesn't seem to be something BOS can solve. And as you've seen, it's only in specific discs/OS/filesystem combinations that it breaks. Sorry for continually pushing the issue up the chain!However, I decided to try narrow it further and it seems to only hang when enumerating files recursively (SearchOption.AllDirectories). Limiting the recursion to some small number prevents it hanging.
Reading the protection output of recursion around
9showed the problem: it was openingSteamInstall.sizes/.bom/.pax.gzas directories, but not traversing anywhere. So it is infinitely recursing the same folder. I also cannot seem to read these three files in Windows either, even with Admin rights. Any ideas?@Deterous commented on GitHub (Jan 18, 2024):
sudo mount -t udf -o loop FM2012.iso /mnt/dcd Install\ FM2012.app/Contents/Resources/SteamInstall.pkg/Contents/Resources/ls -l .lo and behold, those 3 files are symlinks that go to
''🙃I imagine that ISO9660 filesystem does not support symlinks, so that's why mounting it with
-t iso9660does not recurse@Deterous commented on GitHub (Jan 18, 2024):
Investigating the unreadable symlink:
There doesn't seem to be anything that can be done to truly fix this issue, other than hope that dotnet can change their Linux implementation of Directory.EnumerateFiles, which I have logged here: https://github.com/dotnet/runtime/issues/97123
However I'm unsure how these unreadable symlinks were actually created
@mnadareski commented on GitHub (Oct 23, 2024):
Given this is almost a year old and there's no reasonable fix for this, I will have to close this. This goes well beyond something we can reasonably implement in BOS.