AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (01/09/89)
>Date: Fri, 6 Jan 89 18:23:26 GMT >From: "T.C. Clark" <ulowell!hawk!tclark@BBN.COM> >Subject: ProDos disk organization >I'm trying to recover some data on a 3.5" disk and was wondering if >someone could give me a brief idea of how ProDos disks are organized. >I've deciphered some of block #2 as far as the 16 byte file and >directory names followed by filetype codes. But how about byte >offsets to subdirectories and 'deleted' flags etc...? I second (third? fourth?) the recommendation that you get _Beneath Apple ProDOS_. Also, you ought to consider Bag of Tricks II (Quality Software) and Mr.Fixit (part of Glen Bredon's ProSel) as automatic disk-repair utilities. (It won't take _all_ the fun out of disk repair, though...I get best results when I fix things up by hand so they're reasonable, and then let the utilities take care of the ugly parts, like fixing the bitmap and searching for lots files.) To give you a _little_ info, though: You've already found the 16-byte filename part of a directory entry. The very first byte has the filename's length in the low nibble (the second hex digit), and the high nibbble is the "storage type" for that file. After the filename comes a filetype byte and then 2 bytes for the "key block" number. What is the key block? Depends on the storage type. St type meaning key block ------- ------- --------- 0 deleted not meaningful(?) 1 seedling file the only block in the file 2 sapling file index block, with up to 256 block #s (see below) 3 tree file index block pointing to other index blocks 4 Pascal Area (?) [not used by ProDOS] 5 extended file Used by GS/OS's ProDOS File System Translator to provide files with 2 "forks"; can't remember the format off top of head. $D subdirectory first block of directory (the 1st 4 bytes of every directory block are backwards and forwards links to other dir blocks) $F volume dir marks a disk directory (you'll find one of these in block 2) Index blocks have a nifty format: the low bytes of the block numbers are stored in the first half (first 256 bytes) of the block, and the high bytes are stored in the high half. So if blocks numbered $1fd, $1fe, $1ff, $200, and $345 happen to be the 5 blocks in some "sapling" file, then the key block will look like this: $000:fd fe ff 00 45 00 00 00 00 00 00 00 00 00 00 $010:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .. $100:01 01 01 02 03 00 00 00 00 00 00 00 00 00 00 $110:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .. $1f0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A "tree" file can handle more than 256 blocks; the key block looks like the one above, except the entries refer to _other_ index blocks (sapling type blocks) instead of actual data blocks. This allows files up to 16 megabytes (32768 blocks). There are important things in subdirectories I haven't mentioned, including the auxtype (2 bytes), and end-of-file position (3 bytes), and some stuff like file-count (2 bytes) near the beginning of a directory. You'll figure a lot of it out by fiddling around, but I really recommend a utility like Mr.Fixit for making sure things are okay; without one, you should copy the recovered files onto a new disk rather than trusting that you didn't leave anything in an unstable state. > tom -----------> tclark@hawk.ulowell.edu --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons