On 09/08/2015 10:01, Johannes Schindelin wrote:
On 2015-08-09 04:01, Adam Dinwoodie wrote:
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.
This is incorrect. MinGW is distinctly *not* a Cygwin fork. MinGW means "Minimal GNU on Windows" and that in turn means that it provides an environment to build executables that purely use the Win32 API. Read: no POSIX emulation whatsoever. Most notably, MinGW programs cannot use fork(2); It is simply unavailable.
What you *probably* meant is that Git for Windows relies on MSys2 for its shell and Perl scripts, and that MSys2 in turn is a fork of Cygwin. That affects *only* the scripts, though; Git itself (as in `git.exe`) is still a pure MinGW program (and as a consequence, is quite a bit faster than Cygwin Git, at the price of certain quirks that Cygwin Git does not suffer).
You're quite right; I'd misread the MinGW page. Thank you for pointing
that out :)
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.
If the desired goal is that Cygwin's link(2) acts like POSIX link(2) on
network drives, I'm not convinced that's possible, at least not by
emulating `core.createObject = rename` in the Cygwin library layer. The
only implementations I can think of would introduce a window condition
between checking for the target file's existence and then clobbering it.
That'd mean the vast majority of the time the Cygwin command would work
as expected, but there'd be race conditions where occasionally a file
gets silently clobbered. Intermittent silent bugs seem much worse than
the command reliably failing.
I think, given that, the current behaviour is preferable: calling link
just errors out in this scenario, because there's no way to map it down
to something that reliably acts like the POSIX call. It's then up to
whatever program is trying to use the call to find an alternative way to
achieve its desired result, and the consequences of that workaround are
the responsibility of the calling application.
In short, as I understand it, this is exactly the scenario
OBJECT_CREATION_USES_RENAMES is intended for.
--
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