Extracting CDOS and CP/M) files

Looking at the first diskette image, it ppears that it's been corrupted somehow (the second one is fine). Take a look at cylinder 1, side 0, sector 1. Near the beginning of the directory we see the entries for two files, FRAME1.MAP, FRAME1.PIX (2 extents) 0020 00 46 52 41 4d 45 31 20 20 4d 41 50 00 00 00 01 0030 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 46 52 41 4d 45 31 20 20 50 49 58 00 00 00 80 0050 04 05 06 07 08 09 0a 0b 00 00 00 00 00 00 00 00 0060 00 46 52 41 4d 45 31 20 20 50 49 58 01 00 00 80 The extents continue for FRAME1.PIX: 00e0 00 46 52 41 4d 45 31 20 20 50 49 58 05 00 00 34 00f0 2c 2d 2e 2f 00 00 00 00 00 00 00 00 00 00 00 00 And then we see a new file, FRAME2.PIX: 0100 00 46 52 41 4d 45 32 20 20 50 49 58 00 00 00 4e 0110 02 03 04 05 06 00 00 00 00 00 00 00 00 00 00 00 But it's allocated using the same clusters as the first two, i.e. 02 03 04 05 06! This is a problem. How did it get that way? Disks swapped, OS bug; any number of other things. But it's clearly wrong. One very ugly way I've seen for this to happen is for a rogue application program to clear part of the BDOS allocation bitmnap in CP/M. We do have the definitions correct; note how the record count in byte offset 0Fh in each directory entry agrees with the number of clusters allocated. This ain't rocket science. 22Disk got it exactly right-- cluster 03 is double-allocated in the directory. I thought it better that 22Disk stop complaining at the first message, since additional warnings won't tell you anything you didn't already know. Sorry to be the bearer of bad news, but I've seen this before--and it's why 22Disk checks for stupid OS tricks like this--and CP/M doesn't until something goes wrong. Cheers, Chuck