Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uiucuxc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!grayson
From: grayson@uiucuxc.UUCP
Newsgroups: net.micro.cpm
Subject: Re: Screen Editor
Message-ID: <34600005@uiucuxc.UUCP>
Date: Tue, 15-Jan-85 21:23:00 EST
Article-I.D.: uiucuxc.34600005
Posted: Tue Jan 15 21:23:00 1985
Date-Received: Tue, 22-Jan-85 05:46:07 EST
References: <20980065@cmu-cs-k.UUCP>
Lines: 18
Nf-ID: #R:cmu-cs-k:-2098006500:uiucuxc:34600005:000:1053
Nf-From: uiucuxc!grayson    Jan 15 20:23:00 1985

Probably the only way is to write zeroes into the directory entries
( and then reset the disk system ).
But this involves knowing how those allocation block numbers are stored
in the directory entries, and this is really a mess.  The allocation
block numbers can be either 1 or 2 bytes in length (you can figure it
out), so there may be either 8 or 16 of them per directory entry.
Even worse, it may happen that there is not a one-to-one correspondence
between directory entries and extents.  A directory entry that addresses
two extents is possible, and then the extent number on the first directory
entry of the file will be 0 or 1, depending on whether the file extends
into the second extent.  The reason for this is that the field which
indicates the number of 128 byte records in the extent is just 1 byte
long, with maximum allowable value of 128.  Thus 16K is the maximum 
extent size.
	It's probably posssible to write the code to shrink the file
portably, but only if you have access to some of these other types of
CP/M systems for debugging.