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

Kevin Ballard <kevin@xxxxxx> · Mon, 21 Jan 2008 21:33:12 -0500

Linus, have you even bothered to read my arguments, or do you just get  
a kick out of building these straw man arguments? You have  
consistently failed to actually address what I'm talking about, and  
instead persist in explaining stuff I already know, as if that was the  
answer to anything I've been talking about. You are clearly incapable  
of understanding my basic point, no matter how simple I break it down.  
I suspect it's because you've been working low-level so long you can't  
think high-level, and so you manage to misinterpret my high-level  
arguments as boneheaded low-level mistakes.

Anyway, please see my countless former emails where I ask to work  
towards a solution instead of just arguing.

-Kevin Ballard

On Jan 21, 2008, at 8:13 PM, Linus Torvalds wrote:

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

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

<<attachment: smime.p7s>>