mirror of
https://github.com/SabreTools/MPF.git
synced 2026-02-03 21:29:27 +00:00
[Problem] Unable to scan for copy protection on UDF disc with Linux MPF.Check #664
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 2, 2024).
Originally assigned to: @mnadareski on GitHub.
Version
What version are you using?
Build
What runtime version are you using?
(I tried both)
Describe the issue
I'm not sure if this is a bug or that I'm using it wrong, but here we go!
I can't seem to be able to scan for copy protection using the Linux version of MPF.Check.
To Reproduce
Steps to reproduce the behavior:
MPF.Check dvdrom pc -s -p /dev/sg0 -u redumper dump_231231_212910_sg0.isoObserved behavior (in Linux version)
It goes from 0% to 100% instantly.
Expected behavior (in Windows)
MPF.Check dvdrom pc -s -p d: -u redumper dump_231231_212910_sg0.iso(Had to attach as too long).
mpf.txt
Additional context
I realise this is likely a BinaryObjectScanner problem, but at the moment I'm not even sure I've got the right syntax for the MPF.Check command.
I've tried with sudo with no difference.
I've tried to pass, instead of /dev/sg0, a folder pointing to the mounted disc, e.g.
MPF.Check dvdrom pc -s -p /run/media/john/FM2012 -u redumper dump_231231_212910_sg0.iso. This just outputs:and never progresses, with MPF.Check using 100% CPU.
Any ideas?
@JohnVeness commented on GitHub (Jan 2, 2024):
After some more investigation, if I copy all the files from the DVD into a subfolder in my home folder (on an SSD), then do
MPF.Check dvdrom pc -s -p /home/john/FM2012 -u redumper dump_231231_212910_sg0.iso, the protection scan proceeds as expected, e.g. like:etc.
This leads me to believe that
-pis intended to point to a folder full of files, not the optical drive block device.Also, mounting the dumped ISO and doing e.g.
MPF.Check dvdrom pc -s -p /home/john/virtual-drives/1/ -u redumper dump_231231_212910_sg0.isoalso works fine.So the remaining problem is trying to run
MPF.Check -s -pand passing the folder name of the "normal" mounted optical disc, the /run/media/etc folder I mentioned earlier, which appears to start at 0.00%, but hang there. I can't work out what would be different in that case.@JohnVeness commented on GitHub (Jan 3, 2024):
I've run MPF.Check in Linux on several more PC DVD discs (http://redump.org/disc/101295, http://redump.org/disc/101296, http://redump.org/disc/42471 and http://redump.org/disc/101524), dumped with redumper, and those ones seem to scan the protection fine using the mounted folder. So I guess there's something particular about http://redump.org/disc/32401 that MPF.Check doesn't like.
I notice that that disc is a PC/Mac disc, if that's the problem. I don't have any other PC/Mac discs I can immediately put my hands on to test this though.
@JohnVeness commented on GitHub (Jan 3, 2024):
Right, getting somewhere. It seems this PC/Mac disc has both an ISO9660 and a UDF filesystem present. By default it mounts as UDF, and MPF.Check fails as mentioned before. If I force it to mount as ISO9660, MPF.Check works fine.
I notice that when mounted in ISO9660 all the filenames are lower-case, whereas in UDF the filenames are in mixed-case. So maybe it's something to do with Windows being case-insensitive in general, and Linux being case-sensitive.
There are also other filename differences, e.g. a file called "Archive.pax.gz" in UDF is called "archivepax.gz" in ISO9660.
@Deterous commented on GitHub (Jan 3, 2024):
It does sound like it's a BOS problem now, try running protection scanning using's the BOS Test program
And then log an issue with BOS
@mnadareski commented on GitHub (Jan 6, 2024):
Interesting, this specific bit of the log:
Indicates that it's trying to scan
/dev/sg0as a file. Not sure why that would be, since I'm relying on .NET things to check for directory or file.@JohnVeness commented on GitHub (Jan 6, 2024):
/dev/sg0 is a file. Well a block device. But it appears as a file. I.e. there isn't /dev/sg0/something/something.
@Deterous commented on GitHub (Jan 9, 2024):
This will be fixed in MPF once https://github.com/SabreTools/BinaryObjectScanner/issues/276 is fixed, and MPF upgrades to a new version of BOS. There's nothing MPF can do.
@mnadareski commented on GitHub (Jan 26, 2024):
Since the issue is in BOS and more specifically, an issue with "empty" symlinks, this issue will be closed and only tracked on the BOS side.