OSX: Foo.c verse foo.c (case insensitve filesystems)
v.ladeuil+lp at free.fr
Wed Sep 26 09:00:30 BST 2007
>>>>> "Bob" == Bob Tanner <tanner at real-time.com> writes:
Bob> I bite myself (again) with the Foo.c vs foo.c on OSX.
Bob> Since hpfs+ is case insensitive I get all sort of issues on file
Bob> or directories dealing with case.
HFS+ is not case sensitive, it's case "preserving" (by default).
Whatever case you use when you create the file/directory is kept.
When you want to *refer* to it, you can use *any* case you want.
ls -l Toto
should exhibit that (I can't try it myself because I activated
the case *sensitive* option when I installed Tiger).
Historically I think the idea was that the user didn't have to
remember the caps it has used (studly caps rings a bell ? :).
The drawback is that you can't have Makefile and makefile in the
same directory (main reason I get rid of that preserving
sillyness as soon as I could).
Bob> First question: Is this issue something that can be
Bob> fixed at the bzr layer or do I need to wait for leopard
Bob> and a case sensitive file system?
You already have an option to HFS+ to make it (at format time)
But be aware that some third-party applications can break (if
they refer to an internal file by 'resource.mine' to a file named
'Resource.Mine' on the filesystem).
Bob> Second question: How can I work around this issue?
Have a look at:
Bob> Scenerio: A lower case directory was renamed to an upper case directory.
Bob> Directory '/path/project/stubby', it was renamed to '/path/project/Stubby'
Bob> $ bzr status
Bob> $ bzr commit
Bob> Commiting revision 153 to "/path/project/".
Bob> bzr ERROR: no changes to commit. use --unchanged to commit anyhow
You can try to work around with bzr mv, but I can't test it
itself so I can't propose a verified solution.
Bob> $ ls -d Stubby
Bob> $ ls -d stubby
Bob> $ ls -a | grep -i stubby
Yes, *that's* case preserving :)
And just for fun what is the ouput of:
ls -d *tubby
More information about the bazaar