On Wed, 13 May 2009, Linus Torvalds wrote:
> 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*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html