🚀 go-pugleaf

In article <3728@cup.portal.com> Dave_Ninjajr_Flory@cup.portal.com writes:
 >Just a small warning if you use Zoomracks II. It will not function with
 >Diskfree. With diskfree loaded ZR will not save to disk. This is real
 >nasty as it will read in your file and then after you have worked on it
 >perhaps for hours, you find you can't save to disk. The first try will
 >rename the original file to backup and create a 0 bytes file. The second
 >try eliminates the backup and makes another 0 byte file. If you don't
 >have a backup of the original file, you are &^()* out of luck.

  This sounds supiciously familiar, but in my case, I found the
problem when trying to do a ymodem-batch download using Flash 1.52.
Unfortunately, I was doing the transfer using a Un*x utility that
would remove the files from the sending machine when my machine
signaled correct reception.  I ended up with 5 files, all 0 bytes
long and no way to recover...  Since I've used Flash 1.52 for batch
file transfers in the past with no problems, this seemed very odd.

  Then I went back to Flash 1.51 and it worked fine.  My assumption
at that time was that my in-use copy of Flash had taken some non-fatal
damage and the 1.51 version was ok...  Now it's starting to look like
there's a bug in DiskFree... but how DiskFree would have such a fatal
effect on renaming a file from Zoomracks is beyond me...

  One other possibility is that TOS may be cheating when it trys to
allocate new sectors.  I could see TOS checking some secret counter
(possibly one that's suppost to be set by the system diskfree) and
saying "nope, no more room" if some special value was found...

  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.

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john