[Gnu-arch-users] Case insensitive file systems [was: tla1.2 on cygwin]

[Parker, Ron]

> From: Tom Lord [mailto:address@hidden
> Sent: Friday, March 05, 2004 11:44 PM

> _If_ you are correct that case issues effect many (I've only ever
> heard you complain) -- there are sane ways to handle that (i.e., with
> a VU namespace handler).

My preferred OS is GNU/Linux, however at work I write Windows code for
construction companies associated with my employer.  One of our competitors
nearly did themselves in trying to force a *nix solution on the same
industry group.  So a borked file system is de rigour for me.

Also, I had personal reasons for needing a couple of notebook computers for
my wife and I.  I did my research and while they did not suit my ideal of
running only free software, a Mac PowerBook and iBook were the best fit for
our needs.  It's a trade off, but I'd rather temporarily run a proprietary
GUI than pay the Microsoft tax.  Also, I really only use free software on
top of Darwin and intend, when time permits, to install and run YDL, Gentoo
or something similar.  The one thing I was unaware and had not seen
documented anywhere prior to purchase was that HFS{+} was case insensitive.
Mea culpa, but nonetheless a reality of my daily life.

> How do you cope with #include, btw?   And, what does tar do?

Where Dustin did not respond to the former, I have at least a partial
answer.  I have never seen a project with two header files which differ only
in case, e.g. String.h and string.h.  If I did, I would likely rearrange it
so that they were in two separate directories and use at least a partial
path in the include statements to differentiate them.  Alternatively I might
prepend or append an underline to one of the names.  The more difficult part
when dealing with developers from a strictly DOS/Windows background is that
it is nearly impossible to get them to use a consistent case in their
include statements and I lack authority to force them to do so.  If the
software is ported to a case-sensitive system, this must be corrected, there
is no way around it.

As for tar IIRC you will typically get one of two reactions depending upon
the port.  I recalling seeing tar abort with an error when it contains a
directory and file that only differ in case.  I think I had a version at one
time that would do the same for case-differing files as well.  Yet another
port silently write out both files under the same name, leaving only the
latest file in the archive on the disk.  None of these solutions is ideal.

FWIW I have seen even large software projects like Perl and XFree86 adjust
to accommodate various file system peculiarities.  At one point in time Perl
had a file named AUX.  This is a reserved legacy device name from MS-DOS and
cannot trivially exist on Windows.  IIRC the Perl developers changed this to
allow for a Cygwin port.  I may be wrong but I think it was XFree86 that had
both a "makefile" and a "Makefile" in its code base.  (This may have also
been Perl or some other large project.  I don't recall exactly.  Its been
too long ago.)

I am not suggesting that tla should be borked because of screwed up file
systems, but I view it from a medical as well as a cultural-social
perspective.  Medically from the Hippocrates' perspective of "First, do no
harm."  And also, culturally in the form of providing a bridge from
proprietary systems to free.  Not to support proprietary systems for
proprietary systems sake, but rather as a bridge to bring them over and
grant them freedom, a Mayflower, so to speak.  It's been my experience that
once having experienced freedom, a person is loath to voluntarily return to
oppression, whatever the form.

Along these lines I ask a few questions.  Is it possible, reasonable,
desirable to have tla guard against creating archives with mixed up cases?
Perhaps by validating that the user is using a case that matches that of the
existing files and directories, essentially reading a directory listing and
making sure that a stricmp==0 item is also strcmp==0, since open is itself
case-insensitive.  I realize this may have to be done for an entire
directory, because on some systems requesting the directory information of a
specific file may also be case-insensitive and may return the exact case
that was originally queried.  The problem I am trying to address is the one
pointed out by Dustin in another email:

>       http://bsdboy.west.spy.net/cgi-bin/viewarch.cgi/address@hidden 
>       -2004s/ViewARCH--devo--0.0.8--patch-21/%7Barch%7D

>       There are three categories people have called this project:

>       ViewARCH
>       ViewArch
>       viewarch

or for that matter one that is seen in Tom's own 2003b archives:

$ tla categories -A address@hidden|fgrep -i labnotes
LabNotes                        <---
LabNotesSystem
labnotes                        <---

Secondarily, is it possible to provide a way out of this morass once it
exists?  I don't know from Dustin's description if his archive has actually
been corrupted or not.  If it has I realize there may be nothing that can be
done, but that takes me back to the "First, do no harm" statement.  I would
hope since tla tries to only write new files to an archive without ever
replacing existing files that this might not be the case and correcting it
might be doable.

Thirdly, and I really don't know enough to even guess at an answer.  Is it
possible to consolidate mismatched categories, branches, etc. on (or from)
case-insensitive systems?

-- 
Ron Parker

An idiot can ask questions and a wise man can answer, but only a fool
rejects truth once he's heard it.