home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0037.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  3.3 KB  |  70 lines
  1. Submitted-by: dominic@british-national-corpus.oxford.ac.uk (Dominic Dunlop)
  2.  
  3. In article <1991Jul3.193837.8849@uunet.uu.net> jdt@voodoo.boeing.com
  4. (Jim Tomlinson) writes:
  5. >
  6. >My organization needs to know (RSN) what, if any, standard file systems
  7. >or directory structures have been dictated or blessed by any of the
  8. >Unix standards organizations.
  9.  
  10. As Mr. Fagan, our moderator, says
  11.  
  12. >[ Jim is asking about filesystem layout, something which is not really
  13. >  standardized...
  14.  
  15. The System V Interface Definition has a fair shot at nailing things
  16. down, but almost nobody has paid any attention.  Even actual
  17. implementations of System V Release [34] don't adhere to it that well.
  18. Apart from that, as far as I am aware, all ``standards'' are [even
  19. more?] proprietary.  Sun has one idea of the Right Way to do things (or
  20. maybe more than one:  they moved stuff around in a recent SunOS
  21. upgrade, and great was the gnashing of teeth among administrators);
  22. Santa Cruz has another idea; IBM yet a third, and so on.  And then
  23. outfits like the X consortium come along and do things which look weird
  24. in any environment.  A directory in /usr/bin?  Hey, wait a minute...
  25. (Although far more heinous crimes are perpetrated by commercial
  26. developers.)
  27.  
  28. To compound the problem, the rules that you are supposed to follow on a
  29. particular platform are, more often than not, undocumented or documented
  30. only eliptically.  If you're lucky, an administration manual will
  31. explain why things are where they are, and you can figure out that your
  32. own files of similar function should be in the same place -- or some
  33. relation of the same place which is set aside for non vendor-supplied
  34. stuff.  If you're really lucky, an application developers' guide will
  35. give you chapter and verse.  You may think it stinks, but at least it's
  36. there in black and white.
  37.  
  38. This is all very unsatisfactory, and we all know what we do in response:
  39. put files in what we think is the right place, independent of what might
  40. or might not be said or implied by the system supplier.  The trouble is,
  41. many of us are using a mental map that was drawn before networking and
  42. file system sharing became so prevalent.  Sun's excuse for moving things
  43. around is that it makes it easier to set up and administer shared files
  44. using NFS -- which is medium restrictive in what it allows one to do.
  45. AT&T's RFS is much less widely used, but allows more flexibility, making
  46. it less important to rearrange the furniture so as to to accommodate its
  47. whims.  And Sun's translucent file system (TFS) may do better still by
  48. creeping up on the problem from a different direction.  (Well, it looks
  49. useful, but I have yet to try it.)
  50.  
  51. What could one standardize?  The Version 7 layout, which ``everybody
  52. knows''?  Hell, no.  I don't want my users under /usr.  And besides,
  53. it's not ``network aware''.  You probably want, wearing your asbestos
  54. underwear, to determine the common subset of current practice, and then
  55. move out from there, causing equal pain to everybody, and bearing in
  56. mind that POSIX standards should always cater for hosted as well as
  57. native environments.
  58.  
  59. Would anybody care to suggest which crack in the POSIX scheme of things
  60. this issue has slipped down and is waitng to crawl out of?  I'd say
  61. it's somewhere beteen 1003.7, administration, and 1003.18, POSIX
  62. environment profile.
  63.  
  64. -- 
  65. Dominic Dunlop
  66.  
  67.  
  68. Volume-Number: Volume 24, Number 38
  69.  
  70.