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