Re: Re-casing directories on case-insensitive systems

[Kevin Ballard <kevin@sb.org>]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

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

> 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



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]