Thank you for your very thorough and conclusive answer! I remember reading something along those lines a long time ago and concluding, "Gosh, Windows sucks," but I couldn't remember enough about it to know whether to bother with an ext2fs test. I might *still* give it a test, but it's now a lower priority, and I have very low expectations.
It sounds like the Windows kernel retains the awkward design that comes from forcing a single-user, desktop OS to do the job of Unix. In 1996, I read that Microsoft wanted to compete with Unix and Novell in the server space. I remember thinking "Good luck!" But it *is* true, what they say -- you cannot make a silk purse out of a sow's ear. On Sun, Apr 13, 2008 at 8:33 PM, Brian Dessent <[EMAIL PROTECTED]> wrote: > Jim Raden wrote: > > > As everyone is aware, git is slower on Windows than on Linux. My > > question is this: would an ext2fs partition on my Windows machine > > speed up git on Windows? (Not that it's that slow -- it's just that > > I'm a bit jealous of those amazingly fast operations on Linux, and > > faster is better, no?) > > Just changing the underlying filesystem driver won't change the API. > Let's take stat() for example: the st_ino member in struct stat will > still always be zero, and st_nlink will always be 1. > > You have to remember that this function "stat" doesn't exist on Windows > as a syscall in any form, it is implemented in userspace by the C > runtime (MSVCRT) in terms of the Win32 API, using FindFirstFile[1] in > this case. And FindFirstFile fills in a struct WIN32_FIND_DATA[2] which > has no members to indicate inode or number of links. So the 'stat' in > MSVCRT can do nothing but fill them in as 0 and 1 always, and so any > code in git that might get a speedup from being able to efficiently get > st_ino from stat will still be equally useless. > > On Windows if you want the inode and number of links you have to first > open the file and then call GetFileInformationByHandle[3]. A different > implementation of 'stat' could in fact do this, and it would be able to > return a sensible "struct stat" with correct and meaningful values even > for NTFS -- it would just be a lot slower. And in fact this is what > Cygwin does, since Cygwin doesn't use anything in MSVCRT but implements > it on its own. > > Anyway, my original point is that the details of the underlying > filesystem cannot matter, because it's an architectural problem: the > design of the API does not allow to get something like the unique inode > number from the filesystem driver without first opening the file. > > Brian > > [1] http://msdn2.microsoft.com/en-us/library/aa364418.aspx > [2] http://msdn2.microsoft.com/en-us/library/aa365740.aspx > [3] http://msdn2.microsoft.com/en-us/library/aa364952.aspx >
