The Perils of Peggy (Part 2) by D.FOWLER2 When last we saw our hero, he was diddling Faithful Nurse Stella, while her erstwhile paramour, Dr. Jameson was dallying with her half-sister ... Ooops, wrong plot line. Let's see. In our last, suspense laden episode Peggy, the Light of my Life, had lost her camp Alumnae Newsletter in a litter of tumbled bits and bytes. Our dauntless disk diver had descended into the dolorous deeps in a desperate dip to discern the dimensions of the disastrous debacle. Oh oh. Watch that alliteration. Anyway, it turned out, at the very least, that the directory track was succotash. Reentering the data was feasible, but not practical. Much of it had been painstakingly extracted from letters and journals sent to Peggy by her Faithful Friends. Time, for our delectable heroine, was in short supply. The deadline was bearing down on her like a runaway D&H locomotive. She was in the midst of three big projects. It was all up to me. I was going to have to troll the brinery deeps for those files. The first thing I had to do was to see if they were still there. Using DU, unrolling a metaphorical string behind me so I could find my way back out, I tip-toed delicately through the disk to see what lurked in the labyrinth. A few spot checks revealed that (so far) the damage was limited to the directory track. Everything else looked sound. But the files were scattered in bits and pieces all over the place. That, of course, is the way a computer works. It looks for the first free space in which to put a file. If the space isn't big enough to take the whole file, it'll stick a bit there, another piece in the next available slot, and log in the directory where the bits and pieces are located. Complicating the hunt, Peggy's single largest file had been worked on several times. Pieces of old versions lurked as decoys amongst the new. To DU and me they all looked the same. Adding to the confusion were fragments of even older files moldering like the mummies in Raiders of the Lost Ark, files that had long ago been erased (marked on the directory track as no longer needed, freeing up the space for re-use) but still on the disk. Well, I consoled myself, at least the data was still there. So, I dug out a rusty old spear from my armory called DOCTOR.COM. (I think I got it from a buddy way back in his TRS 80 days. And we know how long ago THAT was!) The Old Physician was supposed to be able to copy, track by track, from a damaged disk to a fresh one. He was not supposed to unscramble the scrambled track, but it would (I hoped) give me a backup disk to muck around in without risking the main disk. Sadly, either senility had weakened his healing skills, or else a Grue got the good DOCTOR. He plodded along until he hit Track 28 and then started myopically insisting he was getting "Hard Errors". DU had already told me track 28 was in perfect shape. So much for DOCTOR. Obviously it was time to update my armament. Trashed disks being a common hazard, the CP/M software library on GEnie had a half dozen utilities to deal with the problem. I took a chance on a couple, and added the updated version (8.9) of DU to my shopping list. After downloading, un-librarying and uncrunching and the like, I studied what I had. DIRREP21, it turned out, was useful only if you had made a backup copy of your directory ahead of time. So much for THAT one. REPAIR.COM's documentation said it could be used to recover from a trashed directory by allowing me to assemble the file fragments and move them to a new disk under new names. Just what I needed! So, I printed out its documentation (only 2 pages, and reasonably lucid), cranked it up and told it to go to work on the disk in drive B. Over the years I have heard my TEAC disk drives make many different sounds. They whir. They purr softly. They grunt, chuckle and clack. Sometimes I get a disk that ticks. Nice, workman-like sounds. Drive B sounded off like a coffee grinder encountering a pound of rivets. I dislocated my elbow reaching for the reset button. So much for THAT program. I frisbeed the disk across the room. If the window had been open it would have wound up in the pond. I was left with only that one copy of the lost files to work on, and my new, improved, turbo-charged, tail-finned and chrome trimmed version of DU. Like it or not, I was being upgraded from the band-aid and iodine division into open skull neuro-surgery. DU has a raft of talents in addition to showing what is in each sector on a disk. A list, with minimal explanation, of DU's commands would take up two single spaced pages. For one thing, you can use it to change individual bytes. Just for fun I've used it to change WordStar's opening menu to be more cheery on a bleary morning. Hacker fun. Theoretically, by plugging the right bytes in, I could reconstruct the ruined Directory Track that was the source of all our problems. All I needed was an intimate understanding of how addresses are coded, and to determine the address of every piece of every needed file on the disk. Now, the former I understand (I think). Files are stored in Groups (identified by hexadecimal numbers) of eight Sectors. There are ten sectors per track, and 40 tracks on a single sided disk (which this was). And then there's something called Logical Extents, and ... Well, you get the idea. And hey, we're talking getting addresses for fragments of files scattered in 128 (hexadecimal) groups over only 400 (decimal) sectors. And of course, if I messed up ... I didn't waste much time on that approach. An alternative was to suck a sector of file at a time up into RAM (another of DU's talents) and then unload it on to a new disk. A sector holds 128 bytes, about one long sentence. Of course, I had no idea just how big any of the files were supposed to be. Fortunately, files are stored in a logical numerical sequence. DU's (M)ap command gave me a chart of the group numbers under which the files might be stored, but the map came from the bad directory track. Ah hmmm. And I thought Exxon had trouble in Prince William Sound. Well, there seemed nothing to do but to go for it. I could tell DU to go to a Group (the G command), (Y)ank it Sector by Sector into memory, then (L)og on to a new disk in drive A and (S)ave it. Tedious and painstaking, but feasible. And anyway, it was the only avenue still open to me. I automated the pickup stage by stacking DU's commands: D (to display one sector); Z20 (take a nap for two seconds, Turkey, so I can read the display); then, unless I stop you, (Y)ank it into RAM; + (step forward one sector); and repeat (/). The whole command looked like this: D;Z20;Y;+;/. As you've no doubt astutely observed, DU uses the semi-colon to separate commands. To speed the process up I tried Z10, but things moved by too fast, making me dizzy. By keeping track of the sectors before they were slurped up, I hoped to hit "C" to stop the process when I reached the end of that section of the file and before I ran out of runway. Once I got a chunk of file in RAM, I would give it a name and unload it on to a brand new disk. Since not all the groups holding the file were contiguous, I would wind up with each one of Peggy's files in several little heaps, but, if I was lucky, at least it would all be there - I hoped. I was still flying partly blind, thanks to the unreliable map off the directory track. Well, there was nothing to do but take a deep breath, and go for it. Mirabile Dictu! It worked! I looked on the new disk and, Captain, there be files here! The battle was more than half won. Next I simply used my text editor (VDE, of course) to check the heaps out and reassemble them in the right order. The patient was in surgery for about 6 hours, but after a full data transplant he made a complete recovery. Backing up your data is like fastening your seat belt when you get behind the wheel - -you should always do it. Two minutes spent backing up those files in the first place would have avoided the whole problem. But then, I wouldn't have had anything to write about for the last two months, either. Keep the Faith, fans.