Reading 3.5" HD IBM disk -> 2640 kb total / 33 sectors detected about fluxengine HOT 3 OPEN

I think they've tried to copy protect this disk. The total size is garbage because FluxEngine thinks there are 33 sectors per track, because of the presence of sectors 31 and 32.

I'm not sure there's a way around this without very easy but completely specific-to-this-format code in the IBM decoder (for mapping sectors 31 and 32 to 18 and 19) --- it's a couple of lines of code in arch/ibm/decoder.cc.

This is actually a 1638kB extended format disk, by the way.

from fluxengine.

I am surprised that a copy protection is causing this - I never even thought about copy protection on a driver disk. This leaves me a bit embarassed as I was just going through my very small box of my old 3,5" PC disks just to throw anything at FluxEngine to see what would happen. I don't really have a need to create an image of this driver disk. It does not contain the unpublished novel I wanted to rescue (after never writing it in the first place). So this leaves me with the following question:

Should I restrict my usage of FluxEngine to those personal disks that really matter to me - these will probably work flawlessly with FluxEngine as they are standard HD disks.

Or does it make any sense to bother you with this kind of irregular stuff at all - just for learning about what people did back in the 80s and 90s when they created disks commercially. Is there any value in this kind of knowledge today?

I know that reacting to copy protection is not in the scope of this project.

from fluxengine.

In this case, the 'copy protection' looks like it just has two mislabelled sectors in each track. I bet that the software checks that those sectors exist. The DOS filesystem code probably won't try to access them; I bet that FAT is set up for a disk with sectors 0..19, with 18 and 19 marked as bad (as they don't exist).

FluxEngine will read these absolutely fine --- there's no technical reason why they wouldn't work. The only issue is that they're complicated.

For this particular disk, you may be able to get a usable image with -o out.img:s=0-19, which will tell it to write sectors 0 to 19 only; sectors 31 and 32 will be discarded and the missing 18 and 19 will be replaced with zeroes. Of course, if this is copy protection then the code which checks for the non-standard disk format may fail. You might also have good luck with LDBS format which is better at representing non-standard formats.

from fluxengine.