96975089@WSUVM1.BITNET (Ken Smith) (08/03/90)
Can someone send me a good copy of the Quick Sound NDA? the file up on comp.binaries.apple2 is corrupted! the first half of the binscii file has been converted to ALL CAPS! Thanks Alot! Ken Smith Bitnet: 96975089@WSUVM1 Internet: 96975089@wsuvm1.csc.wsu.edu
rhood@pro-gsplus.cts.com (Robert Hood) (06/18/91)
In-Reply-To: message from 881045m@aucs.AcadiaU.ca >I get directory error $51 and error block $2D . The file can't be >copied as a file, only as part of the entire disk. . (It's on a >3.5) I also got I/O error on block $6920 . I thought 3.5 only had >1600 blocks ?!?! I tried to view the file as text and as hex in >CopyII+9.1 no dice . I used the disk mapping utility and the file itself >is fragmented all over the disk. I used GS/OS to get info and it still >gives valid info (ie 16.5k , type , etc) . How can some info still be >there and the rest not(ie the text itself) . Okay, you may be in for a long haul - and you may lose a block or two of the file. IF I'm right. Use Copy II Plus to scan the directory for the name of the file. Using your handy-dandy ProDOS manual, find out which block is the index block of the file - I have a hunch the entry in that section is $6920. The directory is corrupted, in other words, and while the file size/type information is still there, ProDOS can't find the file's index block to read the data. (If I'm wrong, the $6920 reference is in the index block as a block in the file - in that case, shift the other blocks up to remove the reference to $6920 and you'll have most of your information - but you'll have to read the file in as text and manually edit it to salvage the file from AppleWorks.) If the $6920 _is_ in the directory entry, I suggest that you obtain a copy of _Beneath Apple ProDOS_ and key in the "FIB" utility - Find Index Blocks. Will make the job much simpler. What you will have to do is sort of complicated. You must find the index blocks on your 800K disk, list 'em, then do some detective work to figure out which one you want. One way to help in this legwork is to scan the disk for a segment of text that you know is in the latest version of the file - something that will only appear in the "real" index block and not in that of the backup file(s). Then you pore over data dumps for the index blocks you've found until you find one that lists that block. If you find such a block, congratulations - you're almost done. All you have to do is note the index block number and replace the $6920 entry in the directory with the index block number you found - the information should be intact. If you _don't_ find such a block, you're in trouble - it may have been ERASED. Don't worry - just follow me into the Promised Land. You're going to make YOUR OWN index block. Track down all the segments of the file that you can. An easy way to do this is to read the volume bitmap and see what blocks are still marked as used after you strip away all blocks used by other files. (Say blocks 0-35 are marked used. If you have files that take up 7-12, 13-20, and 21-25 plus 30-35, the qualifying blocks would be 26-29.) Then you read those blocks - it helps if you print them out - and try to piece them together into your file. Once you have the file (or as much as you can find) in order, you must create the index block. First, find a free block on the disk. Next, start with a blank block in the block editor. From there, go to hex entry mode and enter the low bytes of the file block numbers. (Say the file is blocks $13, $14, $15, $18, and $20 - you would input "13 14 15 18 20".) When that is done, jump to location $100 in the block - and enter the high bytes of the block numbers in the same order. Finally, write the block to disk. Go to the bitmap and flag the appropriate block as used. Go to the directory entry and plug the block number of the new index block into the entry. That should fix it. If you were able to find the entire file, congratulations - you should be able to read it as is. If not, well, I know the WP module sticks interesting check codes at the start of each line and you'd have to read the "damaged" file in as text - then edit it together. That's all I can think of. If you need help beyond that, email me - preferably with a text copy of the directory block with the entry in question. I'll do what I can. (If it sounds like I'm talking from experience, I am. I used to have a ROM that overheated and would do odd things to the disk drives. Of course, I've only done this on 160K disks - not 3.5" ones - but the theory is the same.) I hope that helped, and (to the rest of the group) I apologize for the long message. ---- ProLine: rhood@pro-gsplus | "Wherever you go...there you are." Internet: rhood@pro-gsplus.cts.com | -- Buckaroo Banzai UUCP: crash!pro-gsplus!rhood | Wanted: An unZIPper for a II! ARPA: crash!pro-gsplus!rhood@nosc.mil | If you have one, let's chat!