X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=HJc2bIdi3IQFkPxk
	VWU2cwnprCIyR3dRTQLDFgr9uzSo5KCg/U8NnNgjH/TZxDuWaSV8V//UIu/kgLuL
	Vqj5lGBBu2qOItNE3DjPbCSpIP3Qhi6xJ0LjHIw7heq6vBZdzBUJLi12t8eEyTio
	nsms7C3YUToRC+a0raik5OaD70s=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=zuu0bIT5KoE4SrQU3kRmTY
	oYk+k=; b=vhprDGQiNKYCxT3eYg+/DLMK7/UlTw4gG9Q5MuQxdzptDb9TL0AI0R
	I1tku8VMSP6gjnvEAU2RvwozBI3cqATlyxQsOVMtasnwqjd8HiHYOb03XKEtF7Is
	IBV1jxnwIhaO3DuiyLmolsD/psdyUhIkbL9Yb2jE17kU50yY8bK1U=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	mail.lysator.liu.se
Message-ID:	<55083FC1.4010503@lysator.liu.se>
Date:	Tue, 17 Mar 2015 15:52:49 +0100
From:	Peter Rosin <peda AT lysator DOT liu DOT se>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version:	1.0
To:	Jason Pyeron <jpyeron AT pdinc DOT us>
CC:	cygwin AT cygwin DOT com
Subject:	Re: [cygwin] Re: git fails to push
References:	<5502264B DOT 3050803 AT lysator DOT liu DOT se> <C31449BA-B14C-4047-981B-6980AB755309 AT etr-usa DOT com> <5508284B DOT 1040304 AT lysator DOT liu DOT se> <E043FEB21B394020B5EA3AFC2ED69308 AT black>
In-Reply-To:	<E043FEB21B394020B5EA3AFC2ED69308@black>

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

- Raw text -