home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / os2 / misc / 25699 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.4 KB

  1. Path: sparky!uunet!cs.utexas.edu!swrinde!gatech!rutgers!ub!dsinc!bagate!cbmvax!cbmehq!cbmger!edohwg!heinz
  2. From: heinz@edohwg.UUCP (Heinz Wrobel)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Re: DOS and OS/2 *Already* are Case sensitive!!!
  5. Message-ID: <heinz.02os@edohwg.UUCP>
  6. Date: 27 Jul 92 00:46:57 GMT
  7. References: <5y!mdjh.feustel@netcom.com>
  8. Organization: Edotronik GmbH
  9. Lines: 62
  10.  
  11. In article <5y!mdjh.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
  12. >Both Dos and OS/2 already are case sensitive since filenames can be
  13. >stored in directories as lowercase. it's just that the
  14. >existing underlying case sensitivity is not handled consistently.
  15.  
  16. They are not "sensitive", they are "preserving". The difference is that
  17. HPFS DOES NOT CARE about case. It just leaves those nice looking letters in
  18. there that you have nice looking filenames. If case really mattered then it
  19. would be case "sensitive".
  20.  
  21. >Providing a switch "DUAL_CASE=[Y|N]" that enables/disables mapping of
  22. >characters to uppercase before name comparisons in DosFindFirst and
  23. >DosFindNext would let everyone use/not use this feature as they
  24. >please.
  25.  
  26. How could you ever switch? There's just NO WAY TO PUT A CASE SWITCH INTO A
  27. FILESYSTEM LIKE HPFS. Let's say you have a >300MB HD in your business in
  28. some network environment with a case "sensitive" filesystem. You'll never
  29. know if you have conflicting filenames somewhere, e.g. "ReadMe" and
  30. "README". Then you switch back to the case preserving mode and all of a
  31. sudden the filesystem will get rather confused. "ReadMe" and "README"
  32. should be the same now!? The technical explanation is:
  33.  
  34.     a) Two filenames that are in the same directory would suddenly be
  35.        identical.
  36.        Option 1: One file will be inaccessible forever.
  37.        Option 2: You'll never know which one the filesystem finds.
  38.        Option 3: The filesystem gets confused and dies.
  39.  
  40.     b) Inside the filesystem hash codes are computed for each filename and
  41.        if it is a good filesystem those hash chains are sorted in a
  42.        reasonable way. Change the hash criteria and you'll die.
  43.  
  44.     c) Try to backup this directory with "ReadMe" and "README" onto a
  45.        floppy and move it to your friends desktop computer. Which file will
  46.        he get if he is not case sensitive? BTW, can you handle floppies
  47.        formatted with a case sensitive filesystem?
  48.  
  49. The only way would be to create a new 'type' of HPFS (let's call it HPFSC)
  50. that is case "sensitive" instead of just being case "preserving". Which
  51. incidently leads to a backup-reformat-restore cycle if you want to switch.
  52.  
  53. THERE CANNOT BE ANY REASONABLE WAY TO CHANGE ON THE FLY FOR A TODAY'S
  54. DESIGN OF A FILESYSTEM.
  55.  
  56. You can always switch from case "preserving" to sensitive automatically,
  57. but if you think about it, you can't go the other way if you don't want to
  58. change your occupation to "filename checker". ;-)
  59.  
  60. BTW, if I'm wrong please email me. I'll be glad to summarize. But really, I
  61. don't think I'm wrong. I've been using case "preserving" filesystems since
  62. 1986 and non preserving one's some years longer like many others. ;-) :-)
  63.  
  64. >Dave Feustel N9MYI <feustel@netcom.com>
  65.  
  66. --
  67. Heinz Wrobel, Edotronik GmbH (ECG018)
  68. FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
  69. Path: cbmehq!cbmger!edohwg!heinz@cbmvax.commodore.com
  70. "It's good to have a mouse, it's faster if you can do without one..."
  71. "He who doesn't develop with an A2024 doesn't know about font independent
  72.  user interfaces..."
  73.