Re: Error writing loose object on Cygwin
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Jul 14, 2006, 05:26 UTC
- Message-ID
- <Pine.LNX.4.64.0607132217360.5623@g5.osdl.org>
- In-Reply-To
- <20060714033435.GA1508@spearce.org>
On Thu, 13 Jul 2006, Shawn Pearce wrote:
Show 6 quoted lines
> > 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