Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!hplabs!hpda!athertn!ericb From: ericb@athertn.Atherton.COM (Eric Black) Newsgroups: comp.sys.amiga Subject: Re: FaccII patch for HardDisks Message-ID: <168@mango.athertn.Atherton.COM> Date: 10 Mar 88 19:32:12 GMT References: <555@io.UUCP> <10116@ulysses.homer.nj.att.com> <10132@ulysses.homer.nj.att.com> <3422@cbmvax.UUCP> Reply-To: ericb@mango.UUCP (Eric Black) Organization: Atherton Technology, Sunnyvale, CA Lines: 32 In article <3422@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes: >In article <10132@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: >> >>For most people's purposes (single fairly slow drive, few multiple task >>disk access and FFS with buffers), FFS will be fine. A product written for >>the slow file system (SFS) would not work under the FFS. ........ > >I beg your pardon? ANY application written for the old file system will work >with FFS. Applications don't give a toss about the disk layout, they just >ask for files from the disk via the filesystem. Since FFS supports all of >the old packet types and returns the same results there are no compatibility >problems. (Except maybe the packets come back too fast :-) Hey, c'mon now! He said "product", not "application", meaning that any FaccII written to intercept calls from "SFS" won't work under FFS. Yes, applications should not know the difference. Yes, filesystem-flavored programs (such as FaccII) could reasonably be expected to be aware of the difference. This has nothing to do with whether or not the new (and breathlessly-anticipated) Fast File System is backwardly-compatible with normal user-level programs. It could very well be that Facc, lacking any special knowledge of the AmigaDOS file system, would work just fine, but FaccII knows about directory layout and such, and takes advantage of that information to make things even faster than they would be doing just a straightforward cacheing of tracks. (I'm certainly looking fo