Re: git on MacOSX and files with decomposed utf-8 file names

>
>
> On Mon, 21 Jan 2008, Linus Torvalds wrote:
>>
>> Think about the file name "Abc", and think about what happens when  
>> you
>> create it.
>>
>> Now, think about what happens if that filename is considered  
>> equivalent in
>> case..
>>
>> See? The filesystem has to *corrupt* the filename.
>
> Let me make this really clear, because I'm afraid that you won't get  
> it
> when I leave out any steps of the way.
>
> Let us say that there is a filename "xyz" that is equivalent to a  
> filename
> "abc" in *any* way. It does not matter if xyz/abc is Hello/hello, or
> whether it's two canonically equivalent strings.
>
> So now, do
>
> 	close(open(xyz, O_WRONLY | O_CREAT, 0666));
> 	close(open(abc, O_WRONLY | O_CREAT, 0666));
>
> and then look at the directory contents afterwards.
>
> There are two, and only two, choices here (*):
> - the filesystem created both files, and they show up as created
> - the filesystem decided they were equivalent, and munged one (or  
> both)
>   of them
>
> Now, let's go back to my claim:
> - munging user data is unacceptable
> and realize that equivalence BY DEFINITION must do it.
>
> So no, you do *not* get to have your cake and eat it too. You simply
> fundamentally *cannot* have both filename equivalence and a non- 
> munging
> filesystem. See above why.
>
> 		Linus
>
> (*) Actually, there is third choice above, which is:
>
> - the filesystem created the first file, and errored out on the second
>   because it noticed it was equivalent - but not identical - to one it
>   already had
>
>   This one is actually a perfectly fine choice, but it's not "your"  
> kind
>   of equivalence, since it actually makes a difference between two
>   equivalent but non-identical names. So the filenames aren't actually
>   interchangable, and this case is really more of a "the filesystem  
> has
>   some very specific limitations on what it allows".
>