Path: utzoo!mnetor!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: DISKFREE
Message-ID: <1016@atari.UUCP>
Date: 14 Mar 88 19:50:00 GMT
References: <704@viper.Lynx.MN.Org>
Distribution: na
Organization: Atari Corp., Sunnyvale CA
Lines: 32

From article <704@viper.Lynx.MN.Org>, by john@viper.Lynx.MN.Org (John Stanley):
>   I know several very knowledgable people at Atari read this
> newsgroup.  Perhaps we could get a little high level debugging 
> help with such a useful utility??  If it is a TOS/BIOS level 
> problem, there's no way anyone but Atari can confirm it.

I forget if I actually responded to the original article -- I think I did.

Part of the problem with DISKFREE is that it circumvents GEMDOS's
internal FAT buffers.  There are up to two of these, meaning two sectors
of the FAT can be out of date with respect to the data on the media. 
This will only happen when there are open files on the media which have
been extended by GEMDOS writes. 

But this still doesn't explain the wholesale zero-length file problems,
because at most this could account for DISKFREE overestimating by 1MB. 

If DISKFREE causes a media change somehow, that would do it -- because
created, unclosed files get closed with zero length and the handles
become invalid (reads and writes return EIHNDL).  If your term program
is dumb enough not to check the return code from the write, and DISKFREE
causes media change on the device, this could be the problem.  

Failing that, I just don't know.  I do know, as a "knowledgeable person
at Atari," that this kind of extra-curricular stuff at the GEMDOS level
is dangerous: the only place I would want a disk utility (a cache, for
instance) is at the RWABS level, which has a well-understood interface
with the rest of the system. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt