Hi Adam, On 2015-08-09 19:05, Adam Dinwoodie wrote: > On 09/08/2015 10:01, Johannes Schindelin wrote: >> On 2015-08-09 04:01, Adam Dinwoodie wrote: >>> >>>> We've gotten a lot of users on the list who ask why their Git >>>> directories on shared drives aren't working (or are broken in some way). >>>> Since I don't use Windows, let me ask: does the Cygwin DLL handle >>>> link(2) properly on shared drives, and if not, would this patch help it >>>> do so? I can imagine that perhaps SMB doesn't support the necessary >>>> operations to make a POSIX link(2) work properly. >>> >>> I'd need to go back to the Cygwin list to get a definite answer, but as >>> I understand it, yes, this is is exactly the problem -- quoting Corinna, >>> one of the Cygwin project leads, "The MS NFS is not very reliable in >>> keeping up with changes to metadata." >>> >>> We have verified that setting `core.createobject rename` resolves the >>> problem for people who are seeing it, which very strongly implies that >>> this build option would solve the problem similarly, but would fix it >>> for all users, not just those who spend enough time investigating the >>> problem to find that setting. >> >> From my experience, it appears that providing Corinna Vinschen (or better put: the Cygwin developers in general) with a sound patch gets things fixed pretty timely. >> >> And since `core.createObject = rename` seems to work around the problem, it should be possible to patch the Cygwin runtime accordingly. Sure, it will take a little investigation *what* code should be changed, and how, but the obvious benefit to *all* Cygwin applications should make that effort worth your while. > > Hmm. I'm not sure what a Cygwin fix would look like here. As I > understand it, using link(2) will fail if the target exists, while > using rename(2) will just clobber a target file. Thanks to you and Junio for explaining why my idea was bad. Sorry! Ciao, Johannes -- 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