Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site microsoft.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!microsoft!markz
From: markz@microsoft.UUCP (Mark Zbikowski)
Newsgroups: net.micro.pc
Subject: RE: re: re: unerase (enough RE's?)
Message-ID: <8703@microsoft.UUCP>
Date: Tue, 24-Jul-84 15:13:37 EDT
Article-I.D.: microsoft.8703
Posted: Tue Jul 24 15:13:37 1984
Date-Received: Fri, 27-Jul-84 03:37:14 EDT
Organization: Microsoft Corporation
Lines: 26

From uw-beaver!cornell!vax135!houxz!houxm!ihnp4!mit-eddie!lkk Wed Dec 31 16:00:00 1969
	"... Erasing the file causes the first byte of the name to be zapped
	with a character (usually an E5 hex) which causes DOS to think it is
	not there. The directory entry contains a pointer to the 1st cluster
	of the file and..."

I hate to be a spoil-sport, but relying on the contents of a directory
entry that was deleted to contain meaningful information is going to cause
you lots of problems.  This is in the same boat as:

	Gee, the current OS is xK long.  Therefore, I'll code my program to use
	the remaining (64-x)K.

	"... HOWEVER, DOS normally allocates free clusters on a basis of taking
	the next free cluster starting from the lowest numbered one available..."

This statement is not only misleading, it is false.  Under 2.0, if MSDOS
is allocating a new file (note the key word new), it scans for free allocation
units beginning at allocation unit 2.

If the file *already* exists, it performs a bi-directional search beginning
at the last allocation unit in the file to find a chain of free allocation
units.

Note that I have said "Under 2.0".  There is absolutely no guarantee *anywhere*
that this algorithm will be used in the future.