Re: Cross-Platform Version Control

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 13, 2009, 21:08 UTC
Message-ID: <alpine.LNX.2.00.0905131639580.2147@iabervon.org>
In-Reply-To: <alpine.LFD.2.01.0905131131240.3343@localhost.localdomain>

On Wed, 13 May 2009, Linus Torvalds wrote:

Show 17 quoted lines

> On Wed, 13 May 2009, Martin Langhoff wrote:
> > 
> > Do we need to take the real solution to the core of git?
> 
> Well, I suspect that if we really want to support it, then we'd better.
> 
> > What I am wondering is whether we can keep this simple in git
> > internals and catch problem filenames at git-add time.
> 
> I can almost guarantee that it will just cause more problems than it 
> solves, and generate some nasty cases that just aren't solvable.
> 
> Because it really isn't just "git add". It's every single thing that does 
> a lstat() on a filename inside of git.
> 
> Now, the simple OS X case is not a huge problem, since the lstat will 
> succeed with the fixed-up filename too.

I'm not seeing what the general case is, and how it could possibly behave.

There's the "insensitive" behavior: if you create "foo" and look for "FOO", it's there, but readdir() reports "foo".

There's the "converting" behavior: if you create "foo", readdir() reports "FOO", but lstat("foo") returns it.

The obvious general case is: if you create "foo", readdir() reports "FOO", and lstat("foo") doesn't find a match. But if you create "foo" again... it doesn't find "foo", so it creates a new file, which it also calls "FOO", and the filesystem now has two files with identical names?

It seems to me that the limits of minimally functional, non-inode-losing filesystems are: lstat() might take a filename and return the data for a non-byte-identical filename; open(name, O_CREAT|O_EXCL) might replace the given name with a non-byte-identical filename. But surely open(name) and lstat(name) (with the same name) must find the same file, even if readdir() would report it with a different name.

And I assume that a filesystem that rejected any non-NFD filenames or any non-NFC filenames would be totally unusable, in that users will manage to get unnormalized filenames into programs and find that the filesystem just doesn't work.

	-Daniel
*This .sig left intentionally blank*