Re: Re-casing directories on case-insensitive systems

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 12, 2008, 01:30 UTC
Message-ID: <7vprw7zv7s.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <B2968E86-D43E-4F5E-921F-DF8A15886C98@sb.org>

Kevin Ballard <kevin@sb.org> writes:

Show 20 quoted lines

> 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.

It's not "my" definition, but you asked the reason and I gave the answer. We can close this issue of "is HFS+ sane" now. HFS+ is insane, period. And as Linus said, you cannot forgive its insanity using the historical baggage argument, like MS-DOS.

HOWEVER.

It is a totally different issue if we want to refuse supporting insane filesystems. And the answer is no. It was not my intention to say that we do not intend to support them, when I explained the reason why the things are as they are, which was the original question by you.

See Robin's proposal to let us translate random names we get back from readdir() from the filesystem using an additional look-up table in the index extension section that stores mapping from canonicalized form to the form that the user registered to the index. I think that is a sane approach to tackle this issue on insane filesystems like HFS+.