"open: No such file or directory" on a certain SCP image

[natevw]

I have a directory full of SuperCard Pro image files (from an actual SCP device via its app). They all process just fine except for one random one which causes a cryptic error in SAMdisk 3.8.8 on macOS 10.14.6:

$ ./samdisk info test.scp
open: No such file or directory
$ file test.scp
test.scp: data
$ ./samdisk info test-404.scp
Error: invalid file: test-404.scp

I've renamed the file, moved it, checked permissions, etc. and it clearly seems to have something to do with the contents of the file rather than the file itself. Any idea what might be wrong?

[natevw]

So I ran this through lldb and discovered that the code is on some path that involves DADiskCreateFromBSDName which was unexpected since this isn't a disk image. That clue led me to BlockDevice code which recognizes a match when BlockDevice::IsFileHDD is true.

Turns out that this file has a size which happens to be an exact multiple of SECTOR_SIZE (512) and so rather than being treated as a SuperCardPro input it got handed to the BlockDevice class instead.

I was able to workaround this by appending an extra byte at the end of the file:

printf '\x00' >> test.scp

Not sure if this would still be an issue in the current version if it tries the SuperCardPro before the other driver, but it certainly seems to give the block device driver first dibs in the last macOS build that's available.

[simonowen]

Thanks for reporting this, and your analysis of the problem.

It all stems from SAMdisk's attempt to work out the type of arguments being passed on the command-line. Once it's decided (perhaps incorrectly) it goes all in on that assumed type, with no way to steer it back in the right direction -- that can lead to some confusing error messages. I think false-positives in IsFileHDD has become more of an issue over time because _MAX_IMAGESIZE been increased from perhaps only 4MiB in early versions to the current 256MiB value, needed to accept multi-revolution flux images.

As a short-term fix I'd recommend having IsFileHDD always return false. I'll make a start on moving the other commands away from the argument detection where possible.

[natevw]

Ah, didn't realize the code published here would still compile on macOS.

A nice feature long-term would be letting us specify the input/output types explicitly instead of from the file and/or its name.