Date   : Wed, 21 Dec 1988 08:45:17 GMT
From   : mcvax!hp4nl!philmds!prle!prles2!prismab!laverman@uunet.uu.net (Bert Laverman)
Subject: Recovering Erased CP/M Files

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>