Path: utzoo!attcan!uunet!aplcen!samsung!zaphod.mps.ohio-state.edu!ncar!mephisto!mcnc!uvaarpa!murdoch!astsun.astro.Virginia.EDU!gl8f From: gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) Newsgroups: comp.sys.atari.st Subject: Re: Re: Full UUCP implementation for the ST? Message-ID: <1990Jul19.173152.1647@murdoch.acc.Virginia.EDU> Date: 19 Jul 90 17:31:52 GMT References: <19896.26a3ddf7@oregon.uoregon.edu> Sender: news@murdoch.acc.Virginia.EDU Organization: Department of Astronomy, University of Virginia Lines: 22 In article steve@thelake.mn.org (Steve Yelvington) writes: >I wrote an rnews program for UUMAIL that unbatched news and wrote >single files to a spool directory. It worked well but slowly -- GEMDOS >is miserably slow in creating new files on a drive that's >three-quarters full. (In my experience, all disk drives are >three-quarters full, except the ones that are completely full.) This is a known and fixed problem in TOS 1.0 and TOS 1.2 that has been discussed here repeatedly. Just like MS-DOS 2.XX, these tos versions pick a new cluster by searching from the start of the FAT, every time. When your drive is mostly full, this takes quite a while. TOS 1.4 has a next-fit algorithm instead, which starts from the last cluster it allocated. If you are running 1.0 or 1.2, you can use FATSPEED to fix this problem. FATSPEED also accellerates finding the number of free bytes on a drive. I have been using FATSPEED for several years and it seems very reliable. -- "In fact you should not be involved in IRC." -- Phil Howard