home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0013.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.2 KB
  1. Date:     Thu, 2 Oct 86 12:43:49 EDT
  2. From: Dan Franklin <im4u!dan@prophet.bbn.com>
  3.  
  4. I can see that it will be hard to emulate POSIX filenames on top of an
  5. operating system such as MS-DOS or VMS, but the benefits of changing the
  6. POSIX spec must be weighed against the costs.  Suppose we changed the spec
  7. so that it permitted a POSIX implementor to provide either a
  8. case-sensitive or case-insensitive filesystem, their choice (which I think
  9. is what Mark is proposing).  There are three groups of people who will be
  10. affected: those who write POSIX emulators, those who write programs for
  11. POSIX, and those who *use* POSIX and its programs.  The last group will be
  12. the largest and most important by far; the emulator writers will be the
  13. smallest group.
  14.  
  15. So how would users be affected?  It might benefit them, because
  16. case-insensitivity might really be better than case-sensitivity.  However,
  17. in the absence of a controlled study, let's assume the null hypothesis:
  18. that it makes no big difference.  More than "proof by assertion" is needed!
  19.  
  20. Regardless of which is really better, some users will probably benefit
  21. because they will be used to other operating systems providing
  22. case-insensitivity, particularly MS-DOS.
  23.  
  24. However, if we really make it an implementor's choice, users will
  25. be hurt by the fact that each POSIX system they encounter will be
  26. different.  In fact, this system-to-system difference will probably
  27. cause more problems than optional case insensitivity would solve.
  28.  
  29. What about people who write POSIX programs?  They will lose.  To the extent
  30. that POSIX permits two possible underlying filesystems, a truly portable
  31. POSIX program will have to be prepared for either one.  For many programs
  32. it may not matter what the FS looks like, but if it does matter, it will
  33. mean extra work.
  34.  
  35. Finally, there are all those emulator writers.  They might find it easier;
  36. then again, they might not.  If I were going to do an emulator on top of
  37. MS-DOS, then (since I don't work for Microsoft) I would probably use the
  38. existing filesystem just as a base to build the POSIX filesystem, almost
  39. the way UNIX builds a named hierarchical filesystem space out of inodes.
  40. Going to case insensitivity wouldn't help me a bit, because of the other
  41. limitations Mark mentioned.  It might help Microsoft, because they could
  42. change the 8+3 convention at the same time.  But unless they were willing
  43. to do that, it wouldn't help them either.  VAX-VMS might be easier, but
  44. again there are other problems I would have to solve.  Case-insensitivity
  45. would help me some, but I'd still have a lot of work ahead of me.
  46.  
  47. But arguments regarding emulator-writing are beside the point.  No matter
  48. what POSIX does on this, it will always be possible to write a POSIX
  49. emulator on top of an existing operating system.  So the ease of *using*
  50. the system must take precedence over the ease of writing it.
  51.  
  52. For the reasons above, I believe that making case-insensitivity an *option*
  53. would be a bad idea.  Changing the spec to *insist* on case-insensitivity
  54. might be a good idea, but it would cause enough problems w.r.t. existing
  55. UNIX systems that it ought to be very strongly motivated.  To start with:
  56. is it really much easier for people to use such a system?
  57.  
  58.     Dan Franklin
  59.  
  60. Volume-Number: Volume 7, Number 14
  61.  
  62.