<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Thu, 10 Mar 1988 13:12:10 PST
From   : pnet01!mwilson@nosc.mil
Subject: CP/M disk directories

Ok, all you CP/M mavens, here's a good question for you.  Not anything earth-
shattering, or anything like that... just irritating.

The scenario:  Disk B: is a DSDD 48 tpi drive.  It uses 8-bit allocation
groups, so 16 groups can be allocated in one directory extent.  The group
size is 2k, so each extent can address 32k.  That, I have no problem with.
What I have problems with is how the damn files are represented in the
directory.  A short example session follows.


B0:WORK>save 511 test.fil s                 ; create a file in 2 extents
                                               ; minus 1 record
SAVE, Version 0.4 (loaded at B000H)
  TEST    .FIL saved
B0:WORK>
B0:WORK>stat test.fil                               ; check it out


 Recs  Bytes  Ext Acc
  511    64k    2 R/W B:TEST.FIL               ; Ok, 511 recs in 2 extents
Bytes Remaining On B: 154k

B0:WORK>stat b:dsk:


    B: Drive Characteristics
 3120: 128 Byte Record Capacity
  390: Kilobyte Drive  Capacity
  128: 32  Byte Directory Entries
  128: Checked  Directory Entries
  256: Records/ Extent                         ; Wait!  How is this done?
   16: Records/ Block                          ; Isn't the RC byte limited to
   40: Sectors/ Track                          ; a maximum of 80h records?
    2: Reserved Tracks

; Ok, now we look at the directory...

B0:WORK>

DU3  B0? s5
Group = 00:04, Track = 2, Sector = 5, Physical Sector = 4              

DU3  B0? d
00  005A3830 444F5331  30444F43 01000001  |.Z80DOS10DOC....|
10  45464748 494A4B4C  4D000000 00000000  |EFGHIJKLM.......|
20  005A3830 444F5331  305A3830 00000004  |.Z80DOS10Z80....|
30  4F000000 00000000  00000000 00000000  |O...............|
40  005A3830 4454494D  455A3830 0000003E  |.Z80DTIMEZ80...>|
50  35363738 00000000  00000000 00000000  |5678............|
                               vv-------------- extent #1?
                               vv    vv-------- 80h records in this
                               vv    vv         extent?
                               vv    vv
60  00544553 54202020  2046494C 01000080  |.TEST    FIL....|
70  090A0B0C 0E0F101E  393A3B4E 5C5D5E5F  |........9:;N\]^_|

DU3  B0? +d
Group = 00:05, Track = 2, Sector = 6, Physical Sector = 5              
                               vv-------------- extent #3?
                               vv    vv-------- 7fh records in this
                               vv    vv-------- extent?
                               vv    vv
00  00544553 54202020  2046494C 0300007F  |.TEST    FIL....|
10  60616263 64656667  686E6F70 71727374  |`abcdefghnopqrst|
20  00444953 4B202020  20444F43 00000005  |.DISK    DOC....|
30  75000000 00000000  00000000 00000000  |u...............|
40  00434150 20202020  2046494C 00000000  |.CAP     FIL....|
50  00000000 00000000  00000000 00000000  |................|
60  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  |eeeeeeeeeeeeeeee|
70  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  |eeeeeeeeeeeeeeee|


What the @#^&$ happened to extent #0?  I thought I'd have two sequential
extents, numbered zero and 1.  Instead, I get two extents, numbered 1 and
3.  The first one says it has 128 records in it, and the second says it has
127 records in it.  That's only 255 records.  Where'd the rest of 'em go?

And another oddity.  I've been playing with random files lately ( that's
how I got into this mess, trying to prove that BDOS did things the way
the manual says! ), and just for fun, I built a random file that only had
records 0 and 0ffffh in it.  Lowest and highest.  Now, utilities like copy
programs and the like can't deal with this, because there are holes in the
allocation.  I see that.  But the directory above looks like it has holes in
the allocation as well!  Yet PIP/ACOPY/PIPE et. al. can read and copy *this*
file, *correctly*!

What's going on here?!


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marc Wilson
     ARPA: ...!crash!mwilson@nosc.mil
           ...!crash!pnet01!pro-sol!mwilson@nosc.mil
     UUCP: [ cbosgd | hp-sdd!hplabs | sdcsvax | nosc ]!crash!mwilson
     INET: mwilson@crash.CTS.COM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


End of INFO-CPM Digest
******************************
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>