Re: [RFA/libiberty] Darwin has case-insensitive filesystems

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 15 Jun 2011 10:22:36 +0200
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> On Jun 14 18:01, DJ Delorie wrote:
> > 
> > > This is wrong as not all FSs are case insensitive.  In fact HFS+ can
> > > be case sensitive too.  I think you need better check than just
> > > saying all Darwin is case insensitive.  This is just like using
> > > FAT32 on Linux.  In fact I think HAVE_DOS_BASED_FILE_SYSTEM is
> > > incorrect also for NTFS as it can also be case sensitive.
> > 
> > There's a difference between case preserving and case sensitive,
> > though, and we really don't have a portable way to detect
> > case-sensitivity on a per-directory basis, sow how can we do better?
> 
> As Andrew points out, NTFS can be case-sensitive as well, and on Windows
> the case-sensitivity vs. case-preserving behaviour can be chosen for
> each file or directory descriptor at the time the file is opened.
> 
> IMHO it's actually a pity that the filename comparison behaves differently
> on different systems.  I think it would make sense to behave identical on
> all systems.  What about this:  Always search case-sensitive.  If file has
> been found, return.  Otherwise, search case-insensitive.

Over my dead body.  On a proper operating system filenames are
case-sensitive.  Your suggestion would create spurious matches.

Even on case-preserving filesystems I'd argue that treating them as
case-sensitive is still the right approach.  If that creates problems,
it means somebody was sloppy and didn't type the proper name of the
file or some piece of code in the toolchain arbitrarily changed the
case of a filename.  I don't mind punishing people for that.  They
have to learn that on a proper operating system file names are
case-sensitive!

If you're still using an operating system with fully case-insensitive
filesystems, I feel very, very sorry for you.

> Talking about case-insensitive comparison, the filename_cmp and
> filename_ncmp functions don't work for multibyte codesets, only for
> singlebyte codesets.  Given that UTF-8 is standard nowadays, shouldn't
> these functions be replaced with multibyte-aware versions?

For UTF-8, that isn't necessary.  Normal string manipulation functions
work just fine on them, since UTF-8 strings don't contain any embedded
NUL characters.  It's only when you try to be too clever about
case-insensitivity that you run into problems.

> Along the same lines, the entire set of safe-ctype functions only
> work for ASCII and EBCDIC...

That really should only matter for displaying filenames.

Anyway.  I really don't care how deep a hole people have dug for
themselves in trying to support Windows in all its various broken
configurations.  But on a native debugger for a UNIX-like system, or a
cross debugger between such systems, filename_cmp() should simply do a
strcmp().