Hi, On Sat, 23 Dec 2006, Linus Torvalds wrote: > On Sat, 23 Dec 2006, Junio C Hamano wrote: > > > > I have been thinking that we should perhaps change Cygwin > > default to NO_MMAP. Safer but slower would be better than not > > working correctly for people on FAT32. > > The thing is, with a smaller pack access window, it might not even be > slower. I don't know just _how_ many hoops cygwin jumps through for mmap, AFAIK Windows API _does_ have an equivalent to mmap(), which just is not as easy to use. [/me asks my friend Google] Yes. The function is called CreateFile(), and it takes a _filename_, not a file descriptor. Which does not matter much, since Windows is braindead enough not to be able to have files deleted which are still opened. Mind you, renaming is no problem... So, Cygwin has to keep record of the file name (and AFAICT it necessarily fails if mmap() is called with a file descriptor of a file which has been renamed _externally_ after opening) of the file descriptor. Cygwin also has to reopen after a fork(), since Windows does not have fork(), and it has to be simulated by a CreateProcess() and reestablishing existing resources. That is the reason a fork() is really, really expensive on Windows. > and maybe mmap under cygwin is actually perfectly fine, but at the same > time I do suspect that UNIX mmap semantics are a lot harder to emulate > than just a regular "pread()", so it's quite possible that by avoiding > mmap you could avoid a lot of complex cygwin code. But should we really cater for a braindead API? At the time, I _hated_ the fact that we had to change HEAD into a regular file, just because people feared that Windows could not handle symbolic links (and mind you, Cygwin handles them quite gracefully, using .lnk files). Besides, IIRC you said yourself that mmap() is better than pread() when seeking a lot. And pack file accesses _are_ the perfect example for such a use case, no? > And yes, making it all work on FAT32 would obviously be a good thing. If really needed, we could make a hack for Windows, which just adds a new config option automagically set by init-db (on Windows only), and which is checked in gitfakemmap() and gitfakeunmmap(). (BTW I don't like the naming anymore; a good cleanup would be to name them git_mmap() and git_unmmap()). Having said that, if somebody is really dedicated to working on Windows, she could overcome the mentioned problems. There's got to be a way to avoid the error on FAT32 without using NO_MMAP. Don't look at me, I hate Windows, I will not fix it. Ciao, Dscho - 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