PKNIGHT@pucc.Princeton.EDU (Paul Knight) (11/23/88)
Is there any way to recover erased files on a CP/M disk? These are WordStar files on a diskette formatted in a Kaypro machine. Please mail responses to me and I will post a summary to the group.
josef@ugun21.UUCP (11/25/88)
In his note, PKNIGHT@pucc.UUCP writes: > Is there any way to recover erased files on a CP/M disk? These are > WordStar files on a diskette formatted in a Kaypro machine. Ya bet there is! If You look at the CP/M disk directory entry format: uu ff ii ll ee nn aa mm ee ee xx tt ee 00 00 nn || | | || || || ^-- filename.ext --------------^ || ^^-- file size in sectors || ^^-- extent ^^-- user area number or -- 0e5h if erased aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa | | ^-- allocation group numbers --------------------^ Note: The only difference between an unused and a used entry is the user area field value. If the file is erased, it is e5, if not, it is 0 <= uu <= 15 (or so). (Of course, You must somehow take the free blocks into account) There are a number of (PD) programs floating around that do the desired unerasing. BEWARE: You must not do anything after having ERAsed the files. I have one, if You want to, I'll send it to You. Send me Your e-mail address! Josef Moellers paper mail: e-mail: c/o Nixdorf Computer AG USA: uunet!linus!nixbur!nixpbe!mollers.pad Abt. EG-3 !USA: mcvax!unido!nixpbe!mollers.pad Unterer Frankfurter Weg D-4790 Paderborn tel.: (+49) 5251 104691 Standard disclaimer: Blablabla opinion blablabla employer blablabla!
PKNIGHT@pucc.Princeton.EDU (Paul Knight) (12/09/88)
A couple of weeks ago, I posted a request for information on how to
recover CP/M files that had been erased. I asked that responses be
mailed to me and said I would post a summary to the group.
I learned everything I needed to know to accomplish the recovery, and
I gratefully acknowledge the help of the several NETNEWS readers who
responded to my request.
The following message from Dave Goodman (dgee@cup.portal.com) was the
most comprehensive reply, so I post it here by way of summarizing the
contributions of everyone who responded.
*Yes, erased cp/m files can be recovered *provided* the disk has not
*been written to since the erasure took place.
*
*When a file is erased, there is no physical erasure of the disk space
*used by the file. All that happens is the directory entry(ies) for that
*file are marked as erased, with an 0e5h (0xe5 [or E5H], if you prefer)
*in the first (user) field of the directory entry.
*
*Of course, the disk space used by the file is now marked as free, so if
*a subsequent write to the disk is done, the space will be reused and
*the old file will probably be physically overwritten.
*
*Provided the disk has not been written to since the erasure, there are
*two methods of recovering the file.
*
* 1) There is a public domain utility, found on many cp/m bulletin boards,
* called UNERA.COM or UNERASE.COM. Do A>UNERA fname.typ and the file
* will reappear in user area 0.
*
* 2) Alternatively, if your user has a disk editor such as DU.COM or one
* of its many variants, you can look at the actual directory entry(ies)
* on the disk, and change the 0e5h which marks the entry as erased to
* some other plausible value. For example, just change the 0e5h to
* 00h, and the file will reappear in user area 0.
*
*I realize that the above is a bit abstruse if you're not used to dealing
*with the guts of cp/m. If you need more detailed information, feel free
*to e-mail.
Just about the only thing Dave didn't mention was the possibility of
multiple directory entries, to which I was alerted by Bob Bailey
<rlb@cs.odu.edu>, among others:
* Note: If the file(s) were long, there will be multiple
* directory entries. All of the E5Hs must be changed to
* 00H on the lines containing the file names. Actually,
* I should say only change the E5H at the beginning of
* each line!
Again, thanks to all.
- Paul Knightjosef@ugun21.UUCP (12/19/88)
In his note Paul Knight (PKNIGHT@pucc.UUCP) writes: >The following message from Dave Goodman (dgee@cup.portal.com) was the >most comprehensive reply, so I post it here by way of summarizing the >contributions of everyone who responded. >*Yes, erased cp/m files can be recovered *provided* the disk has not >*been written to since the erasure took place. >* >*When a file is erased, there is no physical erasure of the disk space >*used by the file. All that happens is the directory entry(ies) for that >*file are marked as erased, with an 0e5h (0xe5 [or E5H], if you prefer) >*in the first (user) field of the directory entry. >* >*Of course, the disk space used by the file is now marked as free, so if >*a subsequent write to the disk is done, the space will be reused and >*the old file will probably be physically overwritten. My question is: How is free disk space managed? Reason for this question: Some time ago, I had some problems with a self-written program that caused blocks to be souped-up without being registered in a directory entry. What I mean by that is that these blocks seem to be marked as "in use" but not being actually in use. At that time I felt the need for a UN*X-like fsck-program for my system (SB180FX with Z-System). Josef Moellers paper mail: e-mail: c/o Nixdorf Computer AG USA: uunet!linus!nixbur!nixpbe!mollers.pad Abt. EG-3 !USA: mcvax!unido!nixpbe!mollers.pad Unterer Frankfurter Weg D-4790 Paderborn tel.: (+49) 5251 104691 Standard disclaimer: Blablabla opinion blablabla employer blablabla!
wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) (12/21/88)
If I understand your question correctly, you want to know if there is any part of the directory structure or reserved area of the disk that records which blocks are in use. There is no explicit list as in MSDOS or TRSDOS. However, the BDOS maintains a bitmap of allocation blocks that it obtains from the directory entries. One side effect is that under CP/M one can have files that are linked for a single allocation block, and different for later blocks. If you erase one of these linked files, you have the risk of having the BDOS bitmap showing the allocation blocks as being free, when they really are not. I don't know of cases where the blocks can be marked as used when they should be free. I assume that the bitmap is updated or recreated after a control-C and relogging the disk, but I'm not sure. When I've had disks that had linked files ( easy to do after unerasing ) I've played it safe and rebooted after erasing what I did not want.
laverman@prismab.prl.philips.nl (Bert Laverman) (12/21/88)
In article <17700007@ugun21> josef@ugun21.UUCP writes: >My question is: >How is free disk space managed? > Alas a simple answer: it isn't. At least not on disk. Each time a new disk is logged on, BDOS scans the complete directory to find out what parts are used, and builds a block-based-bitmap. This is why CP/M refuses to write on a disk that it hasn't been logged on yet. Most CP/M systems use some kind of CRC check on the directory to find out if a disk has been swapped. BDOS/BIOS design allows for a `drive door open' interrupt. Read any `System Programmers Manual' on the BIOS. >Reason for this question: >Some time ago, I had some problems with a self-written program >that caused blocks to be souped-up without being registered in a >directory entry. >What I mean by that is that these blocks seem to be marked as "in use" >but not being actually in use. >At that time I felt the need for a UN*X-like fsck-program for >my system (SB180FX with Z-System). Well, no fear for that. As soon as you re-log the disk, all non- confirmed changes will be forgotten. What you might get is a dummy file, but no CP/M I know of registers Blocks as `in use' other than by putting them in a directory entry. It may be that the memory based bitmap was updated and not the disk, but one `^C' at prompt level should clear that out. Maybe somebody can write a small program that compares the bitmap to the info found in the directory, creating a `LOSTFILE.DAT' from the overallocated blocks. The bitmap can be found through the Drive Table. Bert Laverman laverman@prismaa.prl.philips.nl #include <standards/disclaimer.h>
frk@frksyv.UUCP (Frank Korzeniewski) (12/21/88)
In article <17700007@ugun21> josef@ugun21.UUCP writes: > [stuff deleted] >At that time I felt the need for a UN*X-like fsck-program for >my system (SB180FX with Z-System). > > > Josef Moellers > > paper mail: e-mail: >c/o Nixdorf Computer AG USA: uunet!linus!nixbur!nixpbe!mollers.pad Several years ago I wrote an "fsck" equivalent for mpm-80 (multi-user cpm) in PL/M. I have since converted it to C for CCPM-86. This utility checks for multiple files allocated to the same disk blocks, scrambled directory entries, other stuff. If there is any interest I will post the source.