Brian, Strange. "Reply All" in Gmail refuses to work with the message you posted at 8:33 p.m. New York time. I had to paste your name in the "To:" field. I know failing to copy everyone in group posts has been a matter of etiquette in this group, and I don't want to be a bad "netizen." :)
- Jim 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 >
