Re: How to work on case-sensitive projects?
Re: How to work on case-sensitive projects?
- Subject: Re: How to work on case-sensitive projects?
- From: Terry Lambert <email@hidden>
- Date: Wed, 07 Oct 2009 10:53:28 -0700
On Oct 7, 2009, at 10:09 AM, Allen Curtis <email@hidden> wrote:
On 6 Oct 2009, at 20:08, Jamison Hope wrote:
Use a case sensitive file system. Have a disk partition formatted
as UFS, or a UFS-formatted disk image and do your svn checkout
there. I don't think Disk Utility can create a UFS disk image, but
hdiutil can.
http://codesnippets.joyent.com/posts/show/2084
I'd strongly recommend against using UFS, actually. Case-sensitive
HFS+ is a much better option.
Well, I am still a little confused about which is case-sensitive vs.
case-preserving. In my case, it must be case-sensitive.
There are two types of file system lookup: directory iteration, and
lookup of individual files. For directory iteration, you go to the
directory and ask it to tell you its contents; for individual file
lookup, you ask it to open a specific name.
A file system can be case insensitive on storage, meaning it stores in
the directory monocase names, or it can be case preserving on storage,
meaning it stores in the directory names as they were given to it by
the software creating the name.
On iteration, a file system can return case insensitive names in
monocase - MS-DOS does this; such names may be returned as all
uppercase because they were stored that way, all lowercase, or, on
some systems, with implied transforms, such as lowercase with the
first letter upper case, the file extension all upper case, the file
extension hidden, etc.. Or it can give you back exactly what you gave
it.
On lookup of individual names, such as in an open(2), chdir(2), chdir
(3), etc., the FS can either be case sensitive on lookup, meaning an
open will only match the exact name stored (or the exact name, after
transformation), or it can be case insensitive on lookup, meaning it
ignores the case for the purposes of finding what it considers an
exact match.
HFS+ by default is case sensitive on storage, case insensitive on
lookup. Since a create operation involves a lookup, this generally
means that if you expand an archive that contains "foo.c" and "FOO.c"
and "FOO.C" on such a system, whichever is first in the archive
determines the case of the stored name, and whichever is last in the
archive determines the contents.
You can turn on case sensitivity on lookup as well to avoid this, but
it requires a rebuild of catalog indices to make the lookups case
sensitive, since a balanced btree implies ordering based on intended
sensitivity on lookups.
BTW: This will be a problem for any Linux kernel developer wishing
to use their Mac for development.
It's unfortunate that your source code is structured in such a way as
to assume so much about FS capabilities and semantics. Such code tends
to reduce its portability to new environments, particulary cross-
compilation environments, by making such assumptions. It makes it very
hard to bootstrap such code to new platforms using cross-compilation
with native tools; one could hope the code would be reorganized to be
more platform independent in the future.
In any case, you can make an HFS+ disk image with the necessary
properties and mount it as an FS, or use the server install option to
create the root volume case sensitive by default, or create a
secondary volume on another disk partition or external drive, or NFS
mount the source code directly from another system that exports it
case sensitively, or any of a lot of other options, such as
reorganizing your source code, etc..
All of these would work around your source organizations assumptions
about its compilation environment.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden