Path: utzoo!utgpu!watmath!clyde!att!rutgers!tut.cis.ohio-state.edu!bloom-beacon!gatech!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!unido!nixpbe!ugun21!josef
From: josef@ugun21.UUCP
Newsgroups: comp.os.cpm
Subject: Re: Recovering Erased CP/M Files
Message-ID: <17700007@ugun21>
Date: 19 Dec 88 07:55:00 GMT
References: <6675@pucc.Princeton.EDU>
Lines: 41
Nf-ID: #R:pucc.Princeton.EDU:-667500:ugun21:17700007:000:1551
Nf-From: ugun21.UUCP!josef    Dec 19 08:55:00 1988


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!