"open: No such file or directory" on a certain SCP image about samdisk HOT 3 OPEN

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.

from samdisk.

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_IMAGE_SIZE 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.

from samdisk.

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.

from samdisk.