Option for marking of the BAD sectors or leaving bad data.

[kaunomedis]

By default, when reading with new disk format option to HFE format, bad sectors are filled with "-=[BAD SECTOR]=-". Is it possible not to fill it with text, but leave salvaged data. Just another option please :)

For CP/M it will save 1K of data...

We can see that there is some readable data in bad sector... Meanwhile:
T9.0: IBM MFM (4/5 sectors) from Raw Flux (10794155 flux in 43071.99ms) (Retry #6.6)
T9.0: Giving up: 1 sectors missing
Even after 6x6 retries the sector is filled with "bad block text".

I don't know, maybe there is such option?

[keirf]

I will have a look how easy this is to implement. I fear the danger with this behaviour by default would be that it would be too easy to "launder" bad sectors to appear good, and this would risk proliferation of subtly broken image files. But as a recovery option I can see the sense in it.

[Telev78]

See this today when i dump a floppy with one bad sector ...
Now the problem is that the raw flux is marked as 100% valid. HxC does not mark the sector as bad, and the same when using gw convert.
Is it possible, for example, to put a bad CRC? Thus the sector will always be indicated as bad.

[keirf]

What was your gw read command line? If you only wanted verification checks and not for the flux file to be "recreated" by the Greaseweazle IBM codec, you could have passed --raw to gw read. But the point about trying to keep data but mark a bad CRC, where possible, is a good one. It is on the to-do with plenty of other stuff.

[Telev78]

ho yes forget the --raw parameter in my command line

edit : now HxC report the bad sector and the gw convert report also the bad sector.
Simply forget the parameter ...

[Telev78]

So, to understand well, there is a difference between
gw read --format ibm.1440 track00.0.raw
and
gw read --format ibm.1440 --raw track00.0.raw

The two commands write in the same output format, but the raw data is different ?

[keirf]

That is correct. The former regenerates the track based on sector data decoded from the original flux. The latter writes the original flux, however it does use the ibm.1440 codec to check for missing sectors so that the usual retry logic works.

[Telev78]

ok now it's make sense. i'm not aware of this difference before.

[keirf]

Your original comment about writing an incorrect CRC in the regenerated track still stands, though. That could still be a good idea. I'm not sure.

[keirf]

Your original comment about writing an incorrect CRC in the regenerated track still stands, though. That could still be a good idea. I'm not sure. It's probably better than trashing the data completely, and writing a good CRC.

[Telev78]

to me, that makes sense. So we realize during the conversion or with other software like HxC that the image has bad sectors.

[kaunomedis]

I like the idea of bad CRC value to mark bad sector, but only AS OPTION.
And I don't know, but some "original" games in 8bit Atari and in Amiga used some "bad sector" trick as copy protection. So, sometimes it is useful to leave CRC and data mismatched.

I not very deep in this- I used gw to salvage some text documents and I was in need to get sector data. Because 1K sector is one page of text and even half page of text is better than full page of dummy text.