Re: [PATCH] config.mak.uname: Cygwin: Use renames for creation

[Adam Dinwoodie <adam@dinwoodie.org>]

On Sat, Aug 08, 2015 at 09:06:28PM +0000, brian m. carlson wrote:
> On Sat, Aug 08, 2015 at 04:47:46PM -0400, Mark Levedahl wrote:
> > On 08/07/2015 04:30 PM, Adam Dinwoodie wrote:
> > >When generating build options for Cygwin, enable
> > >OBJECT_CREATION_USES_RENAMES.  This is necessary to use Git on Windows
> > >shared directories, and is already enabled for the MinGW and plain
> > >Windows builds.
> >
> > I've been supporting use of git on cygwin since about 2008, this issue has
> > never risen that I know. Whatever issue is being patched around here, if
> > truly repeatable, should be handled by the cygwin dll as that code is
> > focused on providing full linux compatibility. If git on linux does need
> > this patch, git on cygwin should not, either. So, I vote against this.

There has been recent and historical discussion on the Cygwin mailing
list about this problem, as well as in other places like Stack Overflow.
I've put a link to one of those discussions on the Cygwin mailing list
in the original patch email.  I can also see some discussiions on this
list that seem related (search archives for "failed to read delta-pack
base object" and "Cygwin").

It may be the technically correct approach that the Cygwin library ought
to fix this, and indeed some improvements have been made in this area.
However given the limited interfaces that Windows offers here, a final
fix is very unlikely to come any time soon, so this patch is the
pragmatic solution.

I do not see any difference between the situation here and the situation
for MinGW, which is fundamentally a Cygwin fork, but which already has
this build option set for it in config.mak.uname.

> 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.

Adam