home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / apple2 / 19492 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  3.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!taligent!apple!city-lights.apple.com!user
  2. From: mattd@apple.com (Matt Deatherage)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: gs.os.FST?
  5. Message-ID: <mattd-260892132155@city-lights.apple.com>
  6. Date: 26 Aug 92 20:28:06 GMT
  7. References: <m0mL8YL-0000olC@crash.cts.com> <1992Aug20.111829.9858@actrix.gen.nz>
  8. Sender: usenet@Apple.COM
  9. Followup-To: comp.sys.apple2
  10. Organization: Developer Technical Support, Apple Computer, Inc.
  11. Lines: 65
  12.  
  13. I normally try really hard to stay out discussions like this.  Just about a
  14. year ago we went through this whole thing about "Why can't we have a new
  15. file system," with the basic answer that creating a new file system that's
  16. totally incompatible with other operating systems (ProDOS 8, HFS, etc.)
  17. just isn't very useful -- by the time you add all the features you want,
  18. it will be just about as slow as HFS and about half as compatible.
  19.  
  20. But I have to comment on some of these things...
  21.  
  22. In article <1992Aug20.111829.9858@actrix.gen.nz>,
  23. David.Empson@bbs.actrix.gen.nz wrote:
  24.  
  25. > Filetypes should be two bytes and auxiliary types four bytes (to allow
  26. > for "future expansion").
  27.  
  28. None of our FSTs currently allow more than one-byte file types and two
  29. byte auxiliary types, and this isn't likely to change.  It is completely
  30. and totally unacceptable to have a file type that can't exist on some
  31. disks.  Thanks to careful file type management, we have enough left to
  32. probably last as long as people ask, provided we keep the scheme in
  33. place.
  34.  
  35. > HFS information can be stored somewhere (possibly in the directory,
  36. > though it seems a waste of space to have it for all files).
  37.  
  38. HFS does this.
  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. HFS does this too.
  44.  
  45. > Otherwise, there is no reason why it cannot be an expanded version of
  46. > ProDOS.  To handle disks larger than 32 megabytes, mutiple disk blocks
  47. > could be combined into "allocation blocks".  To make a 4 gigabyte
  48. > disk, you would need 64k allocation blocks (64k of them).
  49.  
  50. HFS also does this.  This also means that as you get onto large volumes,
  51. you wind up with lots of wasted space.  I have a 230 MB hard drive
  52. on my Quadra 700 at work; creating a two-byte file results in a
  53. logical allocation of 4K.  Get Info says "4K on disk (2 bytes used)".
  54.  
  55. People will complain about this as much as they complain about HFS
  56. speed.  I know you folks; given the opportunity, you'll complain.
  57. :)
  58.  
  59. > Any comments?
  60.  
  61. Yeah; it sounds like you're trying to add all the features of HFS into
  62. something and call it "Not HFS" and hope it's faster.  Good luck.
  63.  
  64. Now can the otherwise talented individuals reading this _please_ spend
  65. their time doing something realistic and productive for Apple II users?
  66.  
  67. > David Empson
  68. > 
  69. > Internet: David.Empson@bbs.actrix.gen.nz    EMPSON_D@kosmos.wcc.govt.nz
  70. > Snail mail: P.O. Box 27-103, Wellington, New Zealand
  71.  
  72. ============================================================================
  73. Matt Deatherage, Developer Support Center, Apple Computer, Inc.
  74. Personal mail only -- please POST technical questions, questions about
  75. Apple and its policies, where to find documents and related inquiries.
  76. The opinions I express don't represent Apple, which makes us both happy.
  77. ============================================================================
  78.