On 2015-03-17 14:33, Jason Pyeron wrote: > Pardon the direct reply, but my posts are blocked.
Perhaps your boilerplate footer with copyright claims, or the raw email addresses? I took the liberty or forwarding it to the list. I hope that was ok. > See: > http://article.gmane.org/gmane.comp.version-control.git/260968 > > https://www.cygwin.com/ml/cygwin/2014-12/msg00096.html > > and the forwarded message below. Interesting. But the patch may not be needed. The easy thing to do seems to be to either use core.createobject = rename or to convince some git :-) that Cygwin also needs OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedTo in its section in config.mak.uname. Reading the explanation for the option in the git Makefile makes me think that this is obviously needed on Cygwin too. "Define OBJECT_CREATION_USES_RENAMES if your operating system has problems when hardlinking a file to another name and unlinking the original file right away (some NTFS drivers seem to zero the contents in that scenario)." NTFS drivers ought to be the same on Windows and Cygwin, and I imaging that Cygwin will have a hard time fixing it up... >> -----Original Message----- >> From: Peter Rosin >> Sent: Tuesday, March 17, 2015 9:13 >> >> On 2015-03-16 22:45, Warren Young wrote: >>> On Mar 12, 2015, at 5:50 PM, Peter Rosin >> <elided> wrote: >>>> >>>> To file:///cygdrive/x/some path/with spaces/repo.git >>> >>> You shouldn't be doing anything shared-database-like to a >> network drive. Network file sharing protocols typically >> either A) do not do locking correctly, or B) they run slow as >> molasses in order to provide proper locking semantics. Since >> almost no one is willing to accept option B), you usually get >> option A). >> > > This seems like the race condition we encountered on __some__ SMB/CIFS > servers. > >> Even if you claim that I shouldn't do something and then list a couple >> of reasons for that, you have no way of knowing if these reasons apply >> or if the alternative is even worse. >> >> I am the only person who has ever pushed to the repo in question. >> Speed is not an issue, I push fairly seldom. The code base is stable. >> >>> I think if you set Git up on the server using one of the >> supported server protocols [*] your problem will go away. >> >> You almost make it sound like file:// isn't a supported >> server protocol. >> Isn't it? If not, why is it listed under "Git on the Server" and why >> is NFS mounts mentioned? > > NFS is different from CIFS/SMB, but it is not the protocol, but the > processing of the files on the remote server. I was unclear, of course NFS is different from CIFS/SMB. I do not use NFS but instead equated them in a broad terms (as in network file systems). >> >> I realize that you are trying to help me work around the problem, but >> finding a workaround isn't my motivation for posting here (I >> have a big >> enough toolbox to find plenty myself). In fact, I don't think the real >> problem is in the git code base. It feels more like some generic file >> access race that manifests itself as freshly created files not being >> found, or something like that. > > Can you compile git your self? You can comment out the check and test. > > I will be happy to update the patch if needed. [Above linked message snipped] Cheers, Peter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
