Case sensitive file names

Guest Moderator, John B. Chambers std-unix at ut-sally.UUCP
Sat Oct 4 03:56:07 AEST 1986


>From im4u!dan at prophet.bbn.com Fri Oct  3 04:42:00 1986
Message-Id: <8610030928.AA14794 at im4u.UTEXAS.EDU>
Date:     Thu, 2 Oct 86 12:43:49 EDT
From: Dan Franklin <im4u!dan at prophet.bbn.com>
To: "Guest Moderator, John B. Chambers" <std-unix%ut-sally.UUCP at im4u.UTEXAS.EDU>
Subject:  Re:  Case sensitive file names

I can see that it will be hard to emulate POSIX filenames on top of an
operating system such as MS-DOS or VMS, but the benefits of changing the
POSIX spec must be weighed against the costs.  Suppose we changed the spec
so that it permitted a POSIX implementor to provide either a
case-sensitive or case-insensitive filesystem, their choice (which I think
is what Mark is proposing).  There are three groups of people who will be
affected: those who write POSIX emulators, those who write programs for
POSIX, and those who *use* POSIX and its programs.  The last group will be
the largest and most important by far; the emulator writers will be the
smallest group.

So how would users be affected?  It might benefit them, because
case-insensitivity might really be better than case-sensitivity.  However,
in the absence of a controlled study, let's assume the null hypothesis:
that it makes no big difference.  More than "proof by assertion" is needed!

Regardless of which is really better, some users will probably benefit
because they will be used to other operating systems providing
case-insensitivity, particularly MS-DOS.

However, if we really make it an implementor's choice, users will
be hurt by the fact that each POSIX system they encounter will be
different.  In fact, this system-to-system difference will probably
cause more problems than optional case insensitivity would solve.

What about people who write POSIX programs?  They will lose.  To the extent
that POSIX permits two possible underlying filesystems, a truly portable
POSIX program will have to be prepared for either one.  For many programs
it may not matter what the FS looks like, but if it does matter, it will
mean extra work.

Finally, there are all those emulator writers.  They might find it easier;
then again, they might not.  If I were going to do an emulator on top of
MS-DOS, then (since I don't work for Microsoft) I would probably use the
existing filesystem just as a base to build the POSIX filesystem, almost
the way UNIX builds a named hierarchical filesystem space out of inodes.
Going to case insensitivity wouldn't help me a bit, because of the other
limitations Mark mentioned.  It might help Microsoft, because they could
change the 8+3 convention at the same time.  But unless they were willing
to do that, it wouldn't help them either.  VAX-VMS might be easier, but
again there are other problems I would have to solve.  Case-insensitivity
would help me some, but I'd still have a lot of work ahead of me.

But arguments regarding emulator-writing are beside the point.  No matter
what POSIX does on this, it will always be possible to write a POSIX
emulator on top of an existing operating system.  So the ease of *using*
the system must take precedence over the ease of writing it.

For the reasons above, I believe that making case-insensitivity an *option*
would be a bad idea.  Changing the spec to *insist* on case-insensitivity
might be a good idea, but it would cause enough problems w.r.t. existing
UNIX systems that it ought to be very strongly motivated.  To start with:
is it really much easier for people to use such a system?

	Dan Franklin

Volume-Number: Volume 7, Number 14



More information about the Mod.std.unix mailing list