Extracting CDOS and CP/M) files

Chuck Guzis cclist at sydex.com
Thu Oct 11 10:39:00 CDT 2007


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








More information about the cctalk mailing list