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.