Re: Error writing loose object on Cygwin

Shawn Pearce [off-list ref] writes:

Has anyone else seen this type of behavior before?  Any suggestions
on debugging this issue?

I would suggest raising this (politely) to Cygwin people.

On Tue, 11 Jul 2006, Junio C Hamano wrote:

Shawn Pearce [off-list ref] writes:

quoted

Has anyone else seen this type of behavior before?  Any suggestions
on debugging this issue?

I would suggest raising this (politely) to Cygwin people.

Well, since it apparently works with W2000, and breaks with XP, I suspect 
it's actually Windows that just returns the wrong error code.

It's entirely possible that we should just make that whole

	if (ret == ENOENT)

go away. Yes, it's the right error code if a subdirectory is missing, and 
yes, POSIX requires it, and yes, WXP is probably just a horrible piece of 
sh*t, but on the other hand, I don't think git really has any serious 
reason to even care. 

So we might as well say that if the link() fails for _any_ reason, we'll 
try to see if doing the mkdir() and re-trying the link helps.

		Linus

Linus Torvalds [off-list ref] wrote:

On Tue, 11 Jul 2006, Junio C Hamano wrote:

quoted

Shawn Pearce [off-list ref] writes:

quoted

Has anyone else seen this type of behavior before?  Any suggestions
on debugging this issue?

I would suggest raising this (politely) to Cygwin people.

Well, since it apparently works with W2000, and breaks with XP, I suspect 
it's actually Windows that just returns the wrong error code.

It's entirely possible that we should just make that whole

	if (ret == ENOENT)

go away. Yes, it's the right error code if a subdirectory is missing, and 
yes, POSIX requires it, and yes, WXP is probably just a horrible piece of 
sh*t, but on the other hand, I don't think git really has any serious 
reason to even care. 

So we might as well say that if the link() fails for _any_ reason, we'll 
try to see if doing the mkdir() and re-trying the link helps.

Hmm.  Its a single mkdir call before we give up and tell the user
something is wrong.  The following change appears to work OK here on
a reasonably POSIX compliant system (OK meaning it reports errors reasonably).

Given that this type of error (failed link) shouldn't happen
that often, except for on Coda or FAT (according to a comment in
move_temp_to_file), I guess the change is OK and comes with little
penalty.  But for Coda and FAT users things are going to slow down a
little bit as we try mkdir for every new loose object being created
before we try rename.

Tomorrow when I get access to my Cygwin system again I'll try to
write up a tiny test case which shows the error behavior we are
seeing and send it to the Cygwin mailing list, as this really does
seem to be a Cygwin or Windows issue.  But of course having GIT
handle this case slightly better wouldn't be bad either.  :-)

diff --git a/sha1_file.c b/sha1_file.c
index 8734d50..db4bddc 100644
--- a/sha1_file.c
+++ b/sha1_file.c

@@ -1336,26 +1336,23 @@ static int link_temp_to_file(const char 
 		return 0;
 
 	/*
-	 * Try to mkdir the last path component if that failed
-	 * with an ENOENT.
+	 * Try to mkdir the last path component if that failed.
 	 *
 	 * Re-try the "link()" regardless of whether the mkdir
 	 * succeeds, since a race might mean that somebody
 	 * else succeeded.
 	 */
 	ret = errno;
-	if (ret == ENOENT) {
-		char *dir = strrchr(filename, '/');
-		if (dir) {
-			*dir = 0;
-			mkdir(filename, 0777);
-			if (adjust_shared_perm(filename))
-				return -2;
-			*dir = '/';
-			if (!link(tmpfile, filename))
-				return 0;
-			ret = errno;
-		}
+	char *dir = strrchr(filename, '/');
+	if (dir) {
+		*dir = 0;
+		mkdir(filename, 0777);
+		if (adjust_shared_perm(filename))
+			return -2;
+		*dir = '/';
+		if (!link(tmpfile, filename))
+			return 0;
+		ret = errno;
 	}
 	return ret;
 }

On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:

Shawn Pearce [off-list ref] writes:

quoted

Has anyone else seen this type of behavior before?  Any suggestions
on debugging this issue?

I would suggest raising this (politely) to Cygwin people.

I lost the thread here but wasn't this referring to a samba mount?  If so,
it would be samba that's returning the wrong "errno".

cgf

Christopher Faylor [off-list ref] wrote:

On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:

quoted

Shawn Pearce [off-list ref] writes:

quoted

Has anyone else seen this type of behavior before?  Any suggestions
on debugging this issue?

I would suggest raising this (politely) to Cygwin people.

I lost the thread here but wasn't this referring to a samba mount?  If so,
it would be samba that's returning the wrong "errno".

I thought about that but Windows 2000 talking to the same samba
server issues back the correct errno.  Running the exact same Cygwin
and GIT binaries (we've at least standardized on that).  So it
seems weird that a samba server is issuing the correct error code
to a Windows 2000 client but the wrong one to a Windows XP client.
(In both cases the clients are accessing directories on the same
filesystem on the UNIX server.)

-- 
Shawn.

On Thu, Jul 13, 2006 at 11:34:35PM -0400, Shawn Pearce wrote:

Christopher Faylor [off-list ref] wrote:

quoted

On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:

quoted

Shawn Pearce [off-list ref] writes:

quoted

Has anyone else seen this type of behavior before?  Any suggestions
on debugging this issue?

I would suggest raising this (politely) to Cygwin people.

I lost the thread here but wasn't this referring to a samba mount?  If so,
it would be samba that's returning the wrong "errno".

I thought about that but Windows 2000 talking to the same samba
server issues back the correct errno.  Running the exact same Cygwin
and GIT binaries (we've at least standardized on that).  So it
seems weird that a samba server is issuing the correct error code
to a Windows 2000 client but the wrong one to a Windows XP client.
(In both cases the clients are accessing directories on the same
filesystem on the UNIX server.)

It's entirely possible that samba is behaving differently with different
versions of windows.  OTOH, I believe that EACCES is the catch-all for
windows errors when translating into errnos so possibly it is an
uncaught error translation.

If you have the inclination and time, if you could run the session
under strace:  "strace -o strace.out git ...",d snip twenty or
thirty lines on each side of the place where the the errno translation
is happening, and send it to the cygwin list at cygwin at cygwin 
maybe something will be obvious.

Note that cygwin's strace is not anything like any other strace and
is quite a bit more wordy so, this file will be pretty large.  That's
why I ask for some careful editing before sending it to the mailing
list.  The errno number for EACCES on cygwin is 13.

cgf

On Thu, 13 Jul 2006, Shawn Pearce wrote:

I thought about that but Windows 2000 talking to the same samba
server issues back the correct errno.  Running the exact same Cygwin
and GIT binaries (we've at least standardized on that).  So it
seems weird that a samba server is issuing the correct error code
to a Windows 2000 client but the wrong one to a Windows XP client.

The samba connection protocol is fairly involved, and it will, as far as I 
know, do a variety of "negotiation" of capabilities of both ends. What a 
W2000 client does can very possibly be very different from what a WXP 
client does, which in turn is certainly going to be different from a W98 
client. It will simply talk a different version of the protocol.

I am also told that the error codes actually differ between different 
versions of the samba protocol - not in the sense that different events 
generate different error codes, but that the _same_ error (say "ENOENT") 
is actually represented wioth different numbering in "old Windows SMB" and 
"new windows SMB".

I don't know the details, and may have gotten them wrong, but the point 
it, is't not at all impossible that the exact same version of Samba on the 
server will negotiate a different protocol because the client OS is 
different, and even though the Cygwin libraries and git binaries are the 
exact same libraries/binaries, they might get different error codes from 
the same system call.

(This may also explain why there are two "samba clients" in the kernel: 
the CONFIG_SMB and CONFIG_CIFS. CIFS is the "new version SMB", and the 
CIFS client currently doesn't even understand the old version - so you 
might use SMB for old servers, and CIFS for new servers)

That said, I thought W2000 and WXP both negotiated the "new" protocol, but 
there are probably config details even within that one..

		Linus