Re: Re-casing directories on case-insensitive systems

From: Kevin Ballard <kevin@sb.org>
Date: Jan 12, 2008, 01:16 UTC
Message-ID: <B2968E86-D43E-4F5E-921F-DF8A15886C98@sb.org>
In-Reply-To: <alpine.LSU.1.00.0801120139170.8333@wbgn129.biozentrum.uni-wuerzburg.de>

On Jan 11, 2008, at 7:40 PM, Johannes Schindelin wrote:

Show 14 quoted lines

> On Fri, 11 Jan 2008, Junio C Hamano wrote:
>
>> Kevin Ballard <kevin@sb.org> writes:
>>
>>> Is there a reason for this? It seems like it would be trivial to end
>>> up with misdiagnosed "untracked" files when using any language other
>>> than English given this behaviuor.
>>
>> No.  The assumption of the code has always been that sane filesystems
>> would return from readdir() the names you gave from creat().
>
> We do not really have to rehash that whole discussion for the Nth  
> time, do
> we?

Apparently so. By Junio's definition, HFS+ is not a sane filesystem, and as git grows more popular with OS X users, this issue is going to crop up more frequently.

According to the HFS+ Volume Format technote[1], filenames in HFS+ are stored in normalized, canonical order. To be more specific, they're stored in a special apple variant of Unicode Normal Form D (the special variant is for preserving round-trip with older encodings with certain codepoint ranges[2]).

In other words, if you hand an HFS+ filesystem a filename that contains unicode characters, what you get back later may be in a different format. And that's going to be a problem if git doesn't deal with this.

[1]: http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties [2]: http://developer.apple.com/qa/qa2001/qa1173.html

Note: CC list stripped because this is a re-sent email, as the list  
bounced the last one that contained a text/html alternate.

-- 
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com