Path: utzoo!attcan!uunet!mcvax!hp4nl!philmds!prle!prles2!prismab!laverman From: laverman@prismab.prl.philips.nl (Bert Laverman) Newsgroups: comp.os.cpm Subject: Re: Recovering Erased CP/M Files Keywords: CP/M, BDOS, Allocation Message-ID: <318@prles2.UUCP> Date: 21 Dec 88 08:45:17 GMT References: <17700007@ugun21> Sender: nobody@prles2.UUCP Reply-To: laverman@prismab.prl.philips.nl (Bert Laverman) Organization: Philips Research Labs Eindhoven Lines: 37 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