[Top][All Lists]
[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>.
signature.asc
Description: This is a digitally signed message part