EDIR V1.0 FOR CP/M 2.2 COMPUTERS FILE UNERASER AND ERASED DIRECTORY ACCESSER INCLUDING ASSORTED FILE RECOVERY PALS AND TECHNIQUES As of 12/14/87 Copyright 1987 by Robert Greenlee P.O. Box 23286 San Diego, California 92123 Telephone: (619) 268-0112 Voice Telephone: (619) 569-8613 Modem ** Frequented Bulletin Boards ** SABALINE: 619-692-1961 ZNODE #9: 619-270-3148 Please tell me what kind of CP/M or MSDOS computer/printer you have so that I can add your name to my mailing list. ==================== Version 1.0 downloaded 12/14/87 for BBS Distribution. Next version to include EDIR machine code routines for Turbo Pascal, dBASE, and BASIC. ==================== EDIR LIBRARY CONTENTS This EDIR software library should contain at least the following files: EDIR.ASM.......Source. EDIR.DOC.......What you're reading now. EDIR.COM.......Erased directory accessing program. Unerases files and more. NO-WRITE.ASM...Source. NO-WRITE.COM...Lost file recovery aid. Allows saving data contained in the free space of a disk into files. A useful worm but be careful! NO-STOP.ASM....Source. NO-STOP.COM....Stops CP/M from waiting for a keypress after every "Bdos Err On B: Bad Sector" message. NO-ERRS.ASM....Source. NO-ERRS.COM....Stops CP/M (BIOS READ) from detecting bad sectors. Useful to enable some COPY programs to copy disks containing bad sectors so that file recovery can be attempted with the copy. (Probably won't work with Kaypro COPY.COM). If you're missing any of the programs then you should still be able to create stripped down but working versions by using DDT as shown below. The stripped down versions don't have sign-on messages. ==================== TABLE OF CONTENTS 1. The EDIR Philosophy and How to Use EDIR. 2. Unerasing Pitfalls - Duplicate Filenames. 3. User Areas - Do you even use them? 4. PIP Tip (Just PIPed over a precious file?) 5. EDIR System Requirements. 6. Creating EDIR.COM with DDT.COM. 7. About unerasing with ERA *.* under EDIR 8. First-Aid for Corrupted Files. 9a. Recovering Lost Files using NO-WRITE (lost files are files which are no longer even listed in the erased file directory). 9b. Recovering Lost Files - One Final Tip. 10. Determining the file sizes of any erased files before unerasing them. 11. Getting Around BDOS Bad Sectors (Using NO-STOP). 12. Getting Around BIOS Bad Sectors (Using NO-ERRS). 13. Original Intent - Unerasing by Telephone. ==================== THE EDIR PHILOSOPHY AND HOW TO USE EDIR Physically CP/M 2.2 has just one file directory per disk. But CP/M can divide its one physical directory into many logical file directories. CP/M lets you easily switch between the many logical file directories with its USERn command. The USERn command can switch between 16 logical file directories which are called User Areas 0 through 15. For example to log into User Area 6 you would use the CP/M command: A>USER 6 . When CP/M first erases a file it only changes one byte of data in the physical file directory. At first glance the change CP/M makes to a file in order to erase it just puts the file into User Area #227. But actually erased files go into a logical erased file directory. This logical erased file directory coexists with the currently active user area. It coexists because whenever a disk write operation is made any directory entries and disk data space required by the write operation are first taken out of the logical erased file directory before any virgin directory entries or disk space is consumed. So once a file is placed into the erased file directory CP/M no longer protects that files data or directory entries from being reused by subsequent disk write operations. To access the forbidden erased file directory, the place where all erased files go and where they start to fade away, I've come up with a small program called EDIR, which is short for Erased DIRectory. What EDIR does is to trick CP/M into actually entering into the erased file directory. Running EDIR, like so: A>EDIR takes you into the erased file directory just as you might change from one drive to another drive or from one user area to another user area. Once inside the erased file directory you can use CP/M's DIR, REN, TYPE, and ERA commands to manipulate the erased files therein. The ERA command will unERAse files back into the currently selected user area. The REN command is handy for renaming any duplicate files before unerasing them. (Try not to unerase a file into a user area which already contains a file of the same name.) Since the erased file directory is a real directory you can run the programs in it. Doing so isn't recommended because many programs just won't work right when run from there. However certain programs like STAT and PIP can be of use when run from the erased file directory. An example of using PIP from there is presented below in the section ABOUT ERASING WITH ERA *.*. An example using STAT is presented below in the section DETERMINING THE FILE SIZES OF ERASED FILES. On most computers EDIR can maintain its influence over CP/M only until the next Warm Boot. So typing Control-C usually gets CP/M back to normal again and takes you out of the erased file directory. Some computers may require a cold boot or system reset to override EDIR and exit from the erased file directory. The files in the erased file directory of a disk are very fragile and can be disturbed anytime data is written onto the disk. The disturbance caused to the erased file directory can range from the permanent loss of the names of files in that directory and/or the overwriting of file data belonging to one or more files in that directory (the latter is almost a certainty). Only immediately after erasing a file is it a sure thing that you'll be able to find that file in the erased file directory and be sure of the integrity of the unerased file. But if after erasing a file you use a program which writes to the disk then you may not even find the name of the file you erased in the erased file directory and even if the name of the erased file is listed in the directory the file might not be totally intact when unerased. The CP/M DIRectory command under EDIR will only show the names of erased files which can probably be completely unerased. So if an erased file has had one or more of its directory entries reclaimed by a subsequent disk write operation then the DIR command would no longer display that files name. However if some of a files directory entries are still left in the directory and you suspect that's so, then the ERA command could still be used to unerase the remaining directory entries, just as would be the case when using UNERA.COM or MAKE.COM. However there's a problem with unerasing incomplete files (files not shown by DIR under EDIR which are missing at least one of their directory entries - which usually means at the very least their first directory entry). When you do so by using ERA under EDIR with a file name not shown by DIR under EDIR (or with programs like UNERA, UNERA+ and MAKE) you end up with a file that's an abomination to CP/M. CP/M won't show the recovered file using DIR, you can't TYPE it, you can't PIP it, DISK.COM can't see it, SWEEP.COM can't open it, but the file will show up in the directory listing displayed by the typical D.COM sorted directory program. Yuck. Now there are solutions to the abominable file problem but I haven't had time to think up something simple yet (if you don't need simple then use DU). So what I suggest you do for now is to use the procedure presented in RECOVERING LOST FILES and don't bother with trying to first recover an incomplete piece of a file. If it doesn't show up using DIR under EDIR then it's a LOST FILE so use the procedure outlined in RECOVERING LOST FILES below. ==================== PITFALLS There are two closely related pitfalls to avoid when unerasing files in the erased file directory. First you should know that in the erased file directory more than one file can have the same name. Second you shouldn't unerase a file which has a name already being used by an unerased file. This is the first obstacle which most UNERA programs can't jump over. You see most UNERA programs will unerase all files having the same filename leaving you with duplicate filenames in the disk directory. So before unerasing files which have the same name you should use the rename command REN to give them different filenames. If you do wind up with duplicate filenames in the unerased file directory one solution would be to erase the duplicates and rename them in the erased file directory before unerasing them again. The problem with having duplicate filenames in the unerased file directory is that you only have access to one of the duplicate files. Unfortunately the REName and ERAse commands effect all files having the same name in the unerased file directory. But fortunately when you're logged into the erased file directory the REName and ERAse commands only effect the first of the duplicate files so that you can rename files which have the same filenames before unerasing them. Another more subtle mind trap awaiting you concerns the many directory programs called D.COM, SD.COM, etc. Most of these programs tell you how many files there are on a disk and how many empty directory entries remain. When getting ready to unerase some files don't outsmart yourself by trying to calculate the number of files and empty directory entries which SHOULD exist once the files have been unerased. Such calculations often comes out wrong. The number of empty directory entries is different from the number of files the disk will hold. That's because a large file can take up more than one directory entry. So more than one directory entry might be consumed by you're unerasing a single file. Anyway it's hard to see any benefit in calculating how many empty directory entries you should end up with. Why bother? ==================== USER AREAS - DO YOU USE THEM? Most hard disk users take advantage of CP/M's ability to place files into different user areas on the hard disk. Because erased files don't belong to any of the valid CP/M user areas the erased file directory doesn't change when you switch user areas. However whenever you unerase a file it goes into the currently logged user area. ==================== PIP TIP It can be useful to know that when PIP.COM (and many other programs and utilities) copies a file onto a disk it first copies to a temporary file and only when and if the copy is entirely successful is any file having the same name erased and the temporary file renamed. What that means is that if you mistakenly copy over a good file using PIP you can recover that good file if you don't copy anything else onto the disk prior to recovering it. ==================== EDIR SYSTEM REQUIREMENTS EDIR only works under genuine CP/M 2.2 Basic Disk Operating System (the BDOS). If you've replaced the CP/M 2.2 Console Command Processor (the CCP) with ZCPR that's ok as long as you haven't also replaced the BDOS part of CP/M. EDIR won't work with ZRDOS. EDIR runs with 8080, 8085, and Z80 CPU's. EDIR works by changing a few locations in the BDOS of CP/M and then returns control back to the CCP part of CP/M. At that point you're logged into the fragile erased file directory, a directory which is both imaginary and real, a directory which could only exist in the outermost reaches of The Twilight Zone. ==================== CREATING EDIR.COM WITH DDT.COM Here's how to use DDT to create a working version of EDIR and save it to disk as a program named EDIR.COM. A>DDT DDT VERS 2.2 -F100,200,1A -S100 0100 1A 2A ,---> 011F 1A 32 ,---> 013E 1A 41 0101 1A 01 | 0120 1A 3F | 013F 1A 00 0102 1A 00 | 0121 1A 01 | 0140 1A 32 0103 1A 25 | 0122 1A 2E | 0141 1A AF 0104 1A 25 | 0123 1A 59 | 0142 1A 00 0105 1A 2E | 0124 1A 11 | 0143 1A 3E 0106 1A 7F | 0125 1A 3B | 0144 1A C8 0107 1A 3E | 0126 1A 01 | 0145 1A 01 0108 1A 22 | 0127 1A 06 | 0146 1A 3E 0109 1A BE | 0128 1A 11 | 0147 1A C9 010A 1A C2 | 0129 1A CD | 0148 1A 32 010B 1A 00 | 012A 1A 32 | 0149 1A 2A 010C 1A 00 | 012B 1A 01 | 014A 1A 00 010D 1A 7C | 012C 1A F1 | 014B 1A C9 010E 1A 32 | 012D 1A 67 | 014C 1A 0F 010F 1A 56 | 012E 1A 2E | 014D 1A 00 0110 1A 01 | 012F 1A 48 | 014E 1A 19 0111 1A D6 | 0130 1A 06 | 014F 1A 7E 0112 1A 04 | 0131 1A 0D | 0150 1A 3D 0113 1A 32 | 0132 1A 1A | 0151 1A E8 0114 1A 4A | 0133 1A 77 | 0152 1A FE 0115 1A 01 | 0134 1A 13 | 0153 1A E4 0116 1A 3D | 0135 1A 23 | 0154 1A C2 0117 1A 32 | 0136 1A 05 | 0155 1A 64 0118 1A 42 | 0137 1A C2 | 0156 1A 00 0119 1A 01 | 0138 1A 32 | 0157 1A F1 011A 1A D6 | 0139 1A 01 | 0158 1A C9 011B 1A 02 | 013A 1A C9 | 0159 1A . 011C 1A F5 | 013B 1A 36 | -^C 011D 1A D6 | 013C 1A E5 | A>SAVE 1 EDIR.COM 011E 1A 02 >---' 013D 1A 3A >---' At this point the file EDIR.COM should now exist in your disk directory. Here's how the EDIR programs code should look when displayed by DDT: A>DDT EDIR.COM DDT VERS 2.2 NEXT PC 0200 0100 -D100,15F 0100 2A 01 00 25 25 2E 7F 3E 22 BE C2 00 00 7C 32 56 0110 01 D6 04 32 4A 01 3D 32 42 01 D6 02 F5 D6 02 32 0120 3F 01 2E 59 11 3B 01 06 11 CD 32 01 F1 67 2E 48 0130 06 0D 1A 77 13 23 05 C2 32 01 C9 36 E5 3A 41 00 0140 32 AF 00 3E C8 01 3E C9 32 2A 00 C9 0F 00 19 7E 0150 3D E8 FE E4 C2 64 00 F1 C9 1A 1A 1A 1A 1A 1A 1A ==================== ABOUT UNERASING WITH ERA *.* For me there is only really scary thing to do with EDIR and that is to unerase all the files at once by using ERA *.*. That's when EDIR performs its toughest trick which is to stop unerasing when it reaches the point in the directory where no file has gone before. For you technical users the way EDIR makes the BDOS detect that point is by checking to see if the sixteenth position in the file control block is the byte value E5h. That works only because most computers initialize the data in the disk directory to the value E5h when formatting a disk. Most computers do. But a few computers do not write the value E5h into every location of the disk directory when formatting a new disk, and so using ERA *.* to unerase all the files on such disks would even turn directory entries which had never before been used into unerased files. That of course would leave you fresh out of directory space. Here's what I do when there are both many unerased files on a disk and many erased files are going to be unerased. First I use EDIR to rename any duplicates among the erased files and then I put a write protect sticker on that disk. Then I prepare an empty disk onto which I then transfer the erased files using PIP.COM before unerasing them. To use PIP.COM to copy the erased files I place EDIR.COM and PIP.COM onto an otherwise blank disk, erase PIP.COM, run EDIR.COM, and then with the disk containing the erased files in drive B I run the erased PIP.COM program on the A drive to transfer all the erased files from drive B onto the empty disk in drive A like so: A>PIP A:=B:*.*[OV] The files which PIP copies end up still being erased files on the disk in the A drive. Then I take the original disk out of drive B and put it aside. Next, still logged onto drive A, I run EDIR again (because PIP caused a Warm Boot when it finished copying which on my computer kicks EDIR out) and use ERA *.* to unerase the files on drive A. At that time I can use ERA *.* with more confidence since I don't have to worry about conflicts with already existing unerased files (because there are none) and besides the original disk will still be intact should something go wrong with the ERA *.* operation. Another potential problem that might come up when using ambiguous file names is that files which are missing directory entries might get unerased. Such files would not be displayed by DIR under EDIR and once unerased they are untouchable. ==================== FIRST-AID FOR CORRUPTED FILES MODIFYING PIP.COM TO FILTER THE END-OF-FILE CODE In certain instances the well equipped file uneraser (you and me) needs to have a program which can filter the CP/M End-of-File marker Control-Z out of an unerased file. Here's one scenario of when you might need it: You have a very large text file which you've accidentally erased. After you erased the file you copied a small file (or files) onto the same disk. Now when you run EDIR the large file shows up in the erased file directory so you unERAse it and then exit EDIR. You check the size of the large file in the unerased file directory and the size seems ok. You feel lucky because you were afraid that copying the smaller file onto the disk might have deleted the name of the big file from the erased file directory. Then you call up the big file you unerased using your word processor but there's some gibberish in the file which looks as if its part of the smaller file which was copied onto the disk after the big file was erased. Where the gibberish ends the file seems to end but that doesn't make sense because the file size indicates there should be quite a bit more in the file. What has probably happened in the scenario above is that when the smaller file was copied onto the disk some of its data copied over some of the data belonging to the big erased file. Among the data belonging to the small file is one or more CP/M Control-Z End-of-File Markers and your word processor (eg. WordStar) won't go beyond the first such marker in a file. What you need to do is to remove all the Control-Z End-of File Markers from the big file so that you'll be able to get at the portion of the big file beyond the gibberish. However you won't be able to recover the data the gibberish covered over, that's gone forever. Here's a patch which can allow PIP.COM to strip all Control- Z End-of-File Markers from a file. The patched version of PIP is called PIPZ. The patch changes PIP's [F] parameter which normally removes Form Feeds so that it filters Control-Z codes instead. Once patched with DDT the new PIP can be used to filter out the unwanted Control-Z codes using the following command line: A>PIPZ FILENAME=FILENAME[FO] The letter O option tells PIP that the entire file is to be filtered so that PIP will not also stop upon encountering the first Control-Z just as your word processor does. The letter F options tells the modified PIP to strip out the Control-Z codes. Here's how to use DDT.COM to modify PIP.COM so that it will filter out Control-Z's (1A Hex): A>DDT PIP.COM DDT VERS 2.2 NEXT PC 2100 0100 -FE54,E54,1A -FE64,E64,1A -^C A>SAVE 32 PIPZ.COM (Above patch to PIP created by Nil R. Olson, N7BCV). ==================== RECOVERING LOST FILES Lost files are files which where unerased but no longer appear in the erased file directory. That can happen because whenever a disk is written to the files in the erased file directory are usually overwritten. However even after the name of an erased file disappears from the erased file directory the data that file contained may be still be wholly or partially intact somewhere on the disk. For example here's a typical scenario: The latest version of your unpublished novel, all 150K of it, was on drive B when you mistakenly erased it and then copied some small 4K files onto the disk. The file name of your novel isn't listed in the erased file directory but you know that those 4K files couldn't have overwritten very much of your 150K novel. You're desperate to retrieve as much of your novel as possible. Even if 8K or so of the novel is permanently gone and sections of it are out of place it would be much easier to repair the damage than to start all over. After all every paragraph is precious! The first thing to do, if you can do it, is to put a write protect sticker on the disk with your novel on it and then make a disk image copy of that disk. All of your attempts at recovering your novel should be made using the copy of your novel disk and not the original, if possible. The reason for using the copy in the following procedure is so that if you make a mistake your novel won't be lost forever. The COPY.COM program used to copy Kaypro disks makes the type of disk image copy I'm referring to in that it copies the entire disk track-by-track and doesn't concern itself with copying individual files the way PIP.COM does. By copying everything on all of the disk tracks the copy will also contain any erased file data present on the original disk. Note: Some COPY.COM programs will abort copying if a bad sector is detected. In that case what you can do is to try running the NO-ERRS program (see below) just before running your COPY.COM program. The NO-ERRS program prevents the detection of bad sectors and so it may fool your COPY.COM program into copying the entire disk. This only works with some COPY.COM programs, probably not with the Kaypro version. Now that you've made a disk image copy of the disk containing your erased novel, and have put the original in a safe place with a write protect sticker on it, what you're going to do next is to create some 32K files on the copy without writing any data onto the disk. In other words you want the 32K files to claim the data already on the disk, hopefully 32K chunks of your erased novel, so that you can then transfer those files off of the disk and begin reconstructing your novel from whatever you find in those files. Here's how to create the 32K files which claim data already on the disk. On another disk create this tiny program which I call NO-WRITE.COM using DDT.COM like so: A>DDT DDT VERS 2.2 -F100,200,1A -S100 0100 1A 3A ,--> 0109 1A C1 ,--> 0112 1A C0 0101 1A 02 | 010A 1A BE | 0113 1A 36 0102 1A 00 | 010B 1A C2 | 0114 1A 01 0103 1A D6 | 010C 1A 00 | 0115 1A C9 0104 1A 04 | 010D 1A 00 | 0116 1A . 0105 1A 67 | 010E 1A 2C | -^C 0106 1A 2E | 010F 1A 36 | A>SAVE 1 NO-WRITE.COM 0107 1A A1 | 0110 1A 01 | 0108 1A 3E >--' 0111 1A 2E >--' At this point the file NO-WRITE.COM should exist on the A drive. Now to start creating the 32K files which will claim data already on the disk instead of writing their own data onto the disk put the copy of the disk containing your erased novel in drive B and log onto drive B. Now use the commands shown below to create the files. Note: If a Warm Boot occurs immediately after you run NO- WRITE then NO-WRITE did not install itself because it didn't see the authentic CP/M 2.2 BDOS which is required in order for NO-WRITE to work. B>A:NO-WRITE B>SAVE 128 FILE1 B>SAVE 128 FILE2 B>SAVE 128 FILE3 B>SAVE 128 FILE4 B>SAVE 128 FILE5 B>SAVE 128 FILE6 Keep creating more files until you get B>SAVE 128 FILE7 the NO SPACE message shown below. NO SPACE Notice the NO SPACE message which was displayed by CP/M after the last SAVE command. That message means that when CP/M was creating FILE7 it ran out of disk space and so FILE7 may not be a 32K file. You must execute the commands shown above one after another exactly as shown without Warm Booting between commands. If you Warm Boot even once between any of the commands then the SAVE commands after the Warm Boot will actually write data onto the disk which will destroy 32K chunks of your erased novel! Now reset your computer in order to get the NO-WRITE program out of the computers memory. Typing Control-C would also probably remove the NO-WRITE program from memory but reset your system anyway just to be sure. Ok so now you have a bunch of 32K chunks of your novel. The first thing you should do now is to filter each of those chunks using the PIPZ program discussed in the section above called "FIRST-AID FOR CORRUPTED FILES." After that it's up to you and your word processor. When you're looking at the recovered 32K chunks using your word processor, let's assume WordStar, you may see lots of very long strings of the lower-case letter e. Those represent empty sectors on the disk which have not been filled with file data even once since the disk was originally formatted. Because each empty logical sector has 128 e's in it if you do a global replace of the e's to get rid of them you should use a string of e's the length of which is an even divisor of 128, such as a string of 8 or 16 e's. RECOVERING LOST FILES - ONE FINAL TIP In the scenario outlined above two small 4K files where copied onto the disk after the 150K novel was erased. If either or both of the 4K files overwrote some of the novel there is a chance that some of the novel might still be left in areas of the disk claimed by, but not used by, the two 4K files. The reason this can be is related to the minimum file size on individual computers. On the Kaypro 2, Kaypro 4, and Kaypro 10 the maximum remaining tidbit of your novel which might remain intact in the disk data space claimed by each of 4K files would be 128 bytes less than 1K, 2K, or 4K respectively. To try and recover such tidbits, assuming they exist, you can start by erasing just those two 4K files. At that point, since the disk would already be completely filled with files because of your previous use of the WRITE-NO/SAVE procedure, the only free space on the disk should be that which was made available by your erasure of the two 4K files. Now repeat the NO-WRITE/SAVE procedure using a different filename in the SAVE command. That will produce a file containing all the data in the disk areas previously claimed by the two 4K files. Finally run the resulting file through PIPZ and you'll be ready to check it for novel data using your word processor. ==================== DETERMINING THE FILE SIZES OF ERASED FILES To see the file sizes of the erased files on drive B place a copy of STAT.COM on drive A and then erase it. Once EDIR is run you can then run the erased STAT.COM to list the file sizes of the erased files on drive B like so: If logged onto drive B use the command B>A:STAT *.* If logged onto drive A use the command A>STAT B:*.* ==================== GETTING AROUND BDOS BAD SECTORS If you have a damaged floppy diskette in drive B and CP/M reads a bad sector from the disk then CP/M will make the announcement "BDOS Err on B: Bad Sector" and suspend operations until you tell it what to do. If you type a Control-C at that point CP/M will cause a Warm Boot. If you type anything other than a Control-C then CP/M will disregard that the data read from the bad sector is probably corrupted and continue operations as if the bad sector had not even been detected. Note: Each bad sector CP/M reports might mean anywhere from 128 to 1024 or more bytes of possibly corrupted data, depending on the physical disk sector size used in your particular computer. When a damaged diskette has a great many bad sectors and you're trying to transfer the damaged files then you might not like having to stay by the computer in order to type a key each time the bad sector message is displayed. So here's a small program which will prevent CP/M from waiting for a keypress. You can create this program, which I call NO-STOP.COM, by using DDT.COM like so: A>DDT DDT VERS 2.2 -F100,200,1A -S100 0100 1A 3A ,--> 0107 1A F7 ,--> 010E 1A 2C 0101 1A 02 | 0108 1A 3E | 010F 1A 36 0102 1A 00 | 0109 1A C1 | 0110 1A C3 0103 1A D6 | 010A 1A BE | 0111 1A C9 0104 1A 0E | 010B 1A C2 | 0112 1A . 0105 1A 67 | 010C 1A 00 | -^C 0106 1A 2E >--' 010D 1A 00 >--' A>SAVE 1 NO-STOP.COM The file NO-STOP.COM should now exist on the A drive. The NO-STOP program, like EDIR and NO-WRITE, will only stay in operation on most computers until a Warm Boot comes along at which time it gets kicked out of the computers RAM memory. So here's exactly what I'd do to copy files from a damaged diskette using PIP.COM. First I'd put a diskette containing only the two files PIP.COM and NO-STOP.COM into drive A. Next I'd put the damaged diskette into drive B. I'd turn on the printer and type Control-P so that I'd have a printed record of the file transfer. Then I'd run NO-STOP and PIP to copy all the files from drive B to drive A like so: A>NO-STOP A>PIP A:=B:*.*[OV] Once PIP started copying the files I'd leave the room and come back later after all the files had been copied. At that point the listing on the printer might look like this: A>NO-STOP A>PIP A:=B:*.*[OV] COPYING - FILENAME1 FILENAME2 FILENAME3 Bdos Err On B: Bad Sector FILENAME4 FILENAME5 Bdos Err On B: Bad Sector Bdos Err On B: Bad Sector FILENAME6 FILENAME7 Of course in a real listing the FILENAME's would be the actual names of files. From the printed listing above I could tell that FILENAME3 had one bad sector and FILENAME5 had two bad sectors. ==================== GETTING AROUND BIOS BAD SECTORS Sometimes you may want to prevent CP/M from even detecting bad sectors. For example many COPY.COM programs which copy disks track-by-track instead of file-by-file bypass the BDOS entirely go straight to the CP/M BIOS. Many of these COPY programs will abort copying if even one bad sector is detected. So here's a small program which will prevent CP/M from detecting bad sectors. You can create this program, which I have named NO-ERRS.COM, by using DDT.COM like so: A>DDT DDT VERS 2.2 -F100,200,1A -S100 0100 1A 3A ,--> 010C 1A 1A ,--> 0118 1A 23 0101 1A 02 | 010D 1A 77 | 0119 1A 36 0102 1A 00 | 010E 1A 3E | 011A 1A AF 0103 1A 57 | 010F 1A 54 | 011B 1A 23 0104 1A 1E | 0110 1A 12 | 011C 1A 36 0105 1A 28 | 0111 1A 23 | 011D 1A C9 0106 1A 21 | 0112 1A 13 | 011E 1A C9 0107 1A 54 | 0113 1A 1A | 011F 1A . 0108 1A 00 | 0114 1A 77 | -^C 0109 1A 36 | 0115 1A 3E | A>SAVE 1 NO-ERRS.COM 010A 1A CD | 0116 1A 00 | 010B 1A 23 >--' 0117 1A 12 >--' At this point the file NO-ERRS.COM should be present in your disk directory. The NO-ERRS program differs from EDIR, NO- WRITE and NO-STOP in that NO-ERRS will survive Warm Boot's. Therefore you must reset your computer in order to stop it from preventing the detection of bad disk sectors. If you make use of the NO-ERRS program in order to allow a COPY.COM type program to copy a disk with bad sectors then the resulting copy will not have any bad sectors. However the bad data in the bad sectors will probably end up in the corresponding good sectors on the copy. That means that on the copy there will be no way to tell which sectors have the bad data in them unless you can visually examine the data. Visual examination can be practical however, especially when the data is text from a novel for example. ==================== ORIGINAL INTENT - UNERASING BY TELEPHONE I began writing EDIR because of a few people who called me asking if there's any way to unerase files without having an UNERA utility which they didn't have (but had just ordered). When a precious file has been erased it can be very hard to wait for an UNERA program to arrive by mail. Especially hard if you have a hard disk since you don't dare write anything onto the hard disk until you first unerase the file(s). The EDIR program and its assorted pals are small enough to be created using DDT.COM in a few minutes. The small program size allows reading the codes over the phone to someone entering them into DDT. Once EDIR is created then recovery of erased files is even easier than using UNERA programs such as UNERA.COM or MAKE.COM. ====================