gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Collins
Subject: Re: [Gnu-arch-users] Case insensitive file systems [was: tla1.2 on cygwin]
Date: Fri, 12 Mar 2004 11:52:01 +1100

On Thu, 2004-03-11 at 04:48, Parker, Ron wrote:

> 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.

I have...

>   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.  

And did something similar. I only did that because we port to windows...

> 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.

Yeah, they key is whether the file system is case insensitive &
preserving, or whether the file system is case sensitive & preserving
with a GUI that completes insensitively.

> 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.)

A number of projects have gone through this.

> 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.

Yeah.

> 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:

No. I think an appropriate solution is a vu tweak for only the systems
that suffer from this problem: MacOS X, windows.

> 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.

The archive has had a bogus changeset created on a case insensitive file
system: it can't be recreated anywhere. The last changeset (maybe more
than one) would need to be removed and recreated correctly.

> 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?

Again, No. The case insensitivity is a feature.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]