home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / apple2 / 19254 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.5 KB
  1. Path: sparky!uunet!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!David.Empson
  2. Newsgroups: comp.sys.apple2
  3. Subject: Re: gs.os.FST?
  4. Message-ID: <1992Aug20.111829.9858@actrix.gen.nz>
  5. From: David.Empson@bbs.actrix.gen.nz
  6. Date: Thu, 20 Aug 1992 11:18:29 GMT
  7. Sender: David.Empson@actrix.gen.nz (David Empson)
  8. References: <m0mL8YL-0000olC@crash.cts.com>
  9. Organization: Actrix Information Exchange
  10. Lines: 50
  11.  
  12. In article <m0mL8YL-0000olC@crash.cts.com> ncp@gnh-cathouse.cts.com (Neal Pitts) writes:
  13. > 
  14. > I believe that there is supposed to be an 18% speed increase in the HFS FST
  15. > when System 6.0.1 (yay!) comes out.  I agree about the "GS/OS FST".  I've been
  16. > hoping something like that would come since System 5.0; I always thought some
  17. > company would come out with such a thing, but Apple never released the specs. 
  18. > I guess this will never happen since Apple feels they have better things to
  19. > do...
  20.  
  21. I was thinking about a hypothetical GS/OS-specific file system last
  22. night, and had a few ideas that others may like to comment on:
  23.  
  24. It should support file and disk sizes up to the full limit of GS/OS
  25. parameters, i.e. 4 gigabytes per file or disk.
  26.  
  27. Filenames should be less restrictive.  I like HFS: 31 characters,
  28. only illegal character is colon.
  29.  
  30. Dates stored on disk should include seconds (for those of us who
  31. frequently compile programs, and use date/time comparisons to work out
  32. whether a source file needs to be recompiled).
  33.  
  34. Filetypes should be two bytes and auxiliary types four bytes (to allow
  35. for "future expansion").
  36.  
  37. HFS information can be stored somewhere (possibly in the directory,
  38. though it seems a waste of space to have it for all files).
  39.  
  40. The fields required to handle the resource fork should be in the
  41. directory, not in an extended file key block.
  42.  
  43. Otherwise, there is no reason why it cannot be an expanded version of
  44. ProDOS.  To handle disks larger than 32 megabytes, mutiple disk blocks
  45. could be combined into "allocation blocks".  To make a 4 gigabyte
  46. disk, you would need 64k allocation blocks (64k of them).
  47.  
  48. Since the allocation block size varies, "sapling" and "tree" files
  49. suddenly get bigger.  With a 512-byte allocation block, a sapling
  50. file can be up to 128k and a tree file up to 16 megabytes.  Every
  51. doubling of the allocation block size quadruples the maximum size of
  52. that storage type (you wouldn't need tree files any more with the
  53. largest allocation block sizes).
  54.  
  55.  
  56. Any comments?
  57. -- 
  58. David Empson
  59.  
  60. Internet: David.Empson@bbs.actrix.gen.nz    EMPSON_D@kosmos.wcc.govt.nz
  61. Snail mail: P.O. Box 27-103, Wellington, New Zealand
  62.