Hi Keith, On Fri, 2 Feb 2018, Keith Goldfarb wrote:
> > On Feb 2, 2018, at 1:18 PM, Johannes Schindelin > > <johannes.schinde...@gmx.de> wrote: > > > > You cannot assume that the inode numbers are identical between file > > systems/operating systems. That's simply not going to work. > > Yes, I agree with you, I cannot assume this, so I checked. In my case, the > inode numbers are indeed identical. > > > I know you really want *so hard* for the same working directory to be > > accessible from both Windows and Linux. I have a lot of sympathy for that > > sentiment. Though I do not see much chance for success on that front. > > I’m certainly willing to accept that there are going to be limitations by > using a filesystem from two different operating systems. But regardless of > the problems caused by that pattern, would you agree that the Windows code > should be using the actual inode number (well, 32-bits of it) instead of zero? In all likelihood, you have enabled the FS Cache feature. And for a good reason: it makes many Git operations much, much faster. Still not as fast as on Linux because Git is quite tuned to assume all the Linux semantics. So instead of using tell-tales for file modifications that are portable, Git uses tell-tales that are readily available on Linux. And instead of using access patterns that are portable, Git assumes POSIX semantics where you simply use opendir()/readdir()/closedir() and in that inner loop, you call lstat() to get all the stat data. This is obviously not portable beyond POSIX. On Windows, for example, there are really fast FindFirstFile()/FindNextFile() APIs that even allow you to specify patterns to match (which Linux has to do manually, by inspecting the file name obtained via readdir()). You even get some stat data back at the same time, really fast, without additional API calls, unlike on Linux. But Git's access patterns really are tuned to the *dir() way, and we have to emulate it in Git for Windows. This is very, very slow. The FS Cache feature tries to gain back some speed by using FindFirstFile()/FindNextFile() pre-emptively and caching the data, looking it up upon the next time stat data is queried. The stat data obtained that way does not, however, include Change Time nor inode number. And that, dear children, was the story for the day: this is why Git for Windows uses the CreationTime instead of the Change Time and why it marks inode as 0; Because to do it accurately would be a lot slower, and we cannot afford even slower because we are already super slow because we have to work around Git's assumptions as to what APIs are available. Ciao, Johannes
