{"thread":{"id":"4858","subject":"Error writing loose object on Cygwin","startedAt":"2006-07-12T03:57:46Z","lastAt":"2006-07-14T05:26:33Z","messageCount":9,"participants":["Shawn Pearce","Junio C Hamano","Linus Torvalds","Christopher Faylor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23685","messageId":"20060712035746.GA7863@spearce.org","threadId":"4858","inReplyTo":null,"subject":"Error writing loose object on Cygwin","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-07-12T03:57:46Z","receivedAt":"2006-07-12T03:57:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I've got a weird bug that a coworker just found today on Cygwin\nrunning on XP.  He was trying to do `git add foo` in a brand new\nrepository which was stored on a Solaris server[*1*] and mounted\non his XP desktop by way of samba[*2*].\n\nMy coworker received the \"unable to write sha1 filename %s:%s\"\nerror in move_temp_to_file during git-add.  After sprinkling some\nprintfs all over that area of sha1_file.c I concluded that GIT was\nreceiving back EACCES as the error from the first link attempt in\nlink_temp_to_file (rather than ENOENT) when the parent directory\ndidn't exist.\n\nReproducing it on XP systems was easy, as was working around the\nproblem:\n\n\tmkdir foo\n\tcd foo\n\tgit init-db\n\techo foo>foo\n\tgit add foo # dies with \"unable to write sha1 filename\"\n\tmkdir .git/objects/25\n\tgit add foo # now succeeds without error\n\nWhat's more interesting is Windows 2000 systems accessing the same\nSolaris server and the same samba server with the same version of\nCygwin didn't have any problems (the first git add succeeded).\n\nThis was Cygwin 1.5.19-4 and 1.4.1.  The tiny patch below fixes\nthe issue for us, but certainly seems like not the best way to go\nabout this...  But right now I've got my coworkers running GIT 1.4.1\nplus the patch below.\n\nHas anyone else seen this type of behavior before?  Any suggestions\non debugging this issue?\n\nFootnotes:\n[*1*] Yes, this Solaris server is the same one that has the old\n      compiler and almost no GNU tools, which means GIT, StGIT,\n\t  cogito and pg's higher level functions are all broken...\n\n[*2*] Yes, Solaris is a real UNIX and the coworker should just use\n      GIT there.  The problem is we have some GIT based scripts which\n      mirror a version control tool that is only available through\n\t  a Java applet running in Internet Explorer on a Windows\n\t  system.  Which means although we can use GIT on Solaris\n\t  there are some operations that we need to execute on\n\t  Windows...\n\n-->8--\nAssume EACCES means ENOENT when creating sha1 objects.\n---\n sha1_file.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 8179630..c04d6a5 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1344,7 +1344,7 @@ static int link_temp_to_file(const char \n         * else succeeded.\n         */\n        ret = errno;\n-       if (ret == ENOENT) {\n+       if (ret == ENOENT || ret == EACCES) {\n                char *dir = strrchr(filename, '/');\n                if (dir) {\n                        *dir = 0;\n-- \n1.4.1\n"},{"id":"23686","messageId":"7vr70r1ms5.fsf@assigned-by-dhcp.cox.net","threadId":"4858","inReplyTo":"20060712035746.GA7863@spearce.org","subject":"Re: Error writing loose object on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-12T04:15:38Z","receivedAt":"2006-07-12T04:15:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> Has anyone else seen this type of behavior before?  Any suggestions\n> on debugging this issue?\n\nI would suggest raising this (politely) to Cygwin people.\n"},{"id":"23688","messageId":"Pine.LNX.4.64.0607112132540.5623@g5.osdl.org","threadId":"4858","inReplyTo":"7vr70r1ms5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error writing loose object on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-12T04:36:04Z","receivedAt":"2006-07-12T04:36:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 11 Jul 2006, Junio C Hamano wrote:\n\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > Has anyone else seen this type of behavior before?  Any suggestions\n> > on debugging this issue?\n> \n> I would suggest raising this (politely) to Cygwin people.\n\nWell, since it apparently works with W2000, and breaks with XP, I suspect \nit's actually Windows that just returns the wrong error code.\n\nIt's entirely possible that we should just make that whole\n\n\tif (ret == ENOENT)\n\ngo away. Yes, it's the right error code if a subdirectory is missing, and \nyes, POSIX requires it, and yes, WXP is probably just a horrible piece of \nsh*t, but on the other hand, I don't think git really has any serious \nreason to even care. \n\nSo we might as well say that if the link() fails for _any_ reason, we'll \ntry to see if doing the mkdir() and re-trying the link helps.\n\n\t\tLinus\n"},{"id":"23690","messageId":"20060712050016.GA8002@spearce.org","threadId":"4858","inReplyTo":"Pine.LNX.4.64.0607112132540.5623@g5.osdl.org","subject":"Re: Error writing loose object on Cygwin","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-07-12T05:00:16Z","receivedAt":"2006-07-12T05:00:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> wrote:\n> On Tue, 11 Jul 2006, Junio C Hamano wrote:\n> \n> > Shawn Pearce <spearce@spearce.org> writes:\n> > \n> > > Has anyone else seen this type of behavior before?  Any suggestions\n> > > on debugging this issue?\n> > \n> > I would suggest raising this (politely) to Cygwin people.\n> \n> Well, since it apparently works with W2000, and breaks with XP, I suspect \n> it's actually Windows that just returns the wrong error code.\n> \n> It's entirely possible that we should just make that whole\n> \n> \tif (ret == ENOENT)\n> \n> go away. Yes, it's the right error code if a subdirectory is missing, and \n> yes, POSIX requires it, and yes, WXP is probably just a horrible piece of \n> sh*t, but on the other hand, I don't think git really has any serious \n> reason to even care. \n> \n> So we might as well say that if the link() fails for _any_ reason, we'll \n> try to see if doing the mkdir() and re-trying the link helps.\n\n\nHmm.  Its a single mkdir call before we give up and tell the user\nsomething is wrong.  The following change appears to work OK here on\na reasonably POSIX compliant system (OK meaning it reports errors reasonably).\n\nGiven that this type of error (failed link) shouldn't happen\nthat often, except for on Coda or FAT (according to a comment in\nmove_temp_to_file), I guess the change is OK and comes with little\npenalty.  But for Coda and FAT users things are going to slow down a\nlittle bit as we try mkdir for every new loose object being created\nbefore we try rename.\n\nTomorrow when I get access to my Cygwin system again I'll try to\nwrite up a tiny test case which shows the error behavior we are\nseeing and send it to the Cygwin mailing list, as this really does\nseem to be a Cygwin or Windows issue.  But of course having GIT\nhandle this case slightly better wouldn't be bad either.  :-)\n\n\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 8734d50..db4bddc 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1336,26 +1336,23 @@ static int link_temp_to_file(const char \n \t\treturn 0;\n \n \t/*\n-\t * Try to mkdir the last path component if that failed\n-\t * with an ENOENT.\n+\t * Try to mkdir the last path component if that failed.\n \t *\n \t * Re-try the \"link()\" regardless of whether the mkdir\n \t * succeeds, since a race might mean that somebody\n \t * else succeeded.\n \t */\n \tret = errno;\n-\tif (ret == ENOENT) {\n-\t\tchar *dir = strrchr(filename, '/');\n-\t\tif (dir) {\n-\t\t\t*dir = 0;\n-\t\t\tmkdir(filename, 0777);\n-\t\t\tif (adjust_shared_perm(filename))\n-\t\t\t\treturn -2;\n-\t\t\t*dir = '/';\n-\t\t\tif (!link(tmpfile, filename))\n-\t\t\t\treturn 0;\n-\t\t\tret = errno;\n-\t\t}\n+\tchar *dir = strrchr(filename, '/');\n+\tif (dir) {\n+\t\t*dir = 0;\n+\t\tmkdir(filename, 0777);\n+\t\tif (adjust_shared_perm(filename))\n+\t\t\treturn -2;\n+\t\t*dir = '/';\n+\t\tif (!link(tmpfile, filename))\n+\t\t\treturn 0;\n+\t\tret = errno;\n \t}\n \treturn ret;\n }\n"},{"id":"23733","messageId":"7vlkqyxh6h.fsf@assigned-by-dhcp.cox.net","threadId":"4858","inReplyTo":"20060712050016.GA8002@spearce.org","subject":"Re: Error writing loose object on Cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-13T04:27:50Z","receivedAt":"2006-07-13T04:27:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> Tomorrow when I get access to my Cygwin system again I'll try to\n> write up a tiny test case which shows the error behavior we are\n> seeing and send it to the Cygwin mailing list, as this really does\n> seem to be a Cygwin or Windows issue.  But of course having GIT\n> handle this case slightly better wouldn't be bad either.  :-)\n\nSurely, and thanks.  I'll await for a follow-up report, and\nuntil then will hold onto this patch.\n"},{"id":"23746","messageId":"20060713055127.GA15960@trixie.casa.cgf.cx","threadId":"4858","inReplyTo":"7vr70r1ms5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Error writing loose object on Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-07-13T05:51:27Z","receivedAt":"2006-07-13T05:51:27Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:\n>Shawn Pearce <spearce@spearce.org> writes:\n>\n>> Has anyone else seen this type of behavior before?  Any suggestions\n>> on debugging this issue?\n>\n>I would suggest raising this (politely) to Cygwin people.\n\nI lost the thread here but wasn't this referring to a samba mount?  If so,\nit would be samba that's returning the wrong \"errno\".\n\ncgf\n"},{"id":"23796","messageId":"20060714033435.GA1508@spearce.org","threadId":"4858","inReplyTo":"20060713055127.GA15960@trixie.casa.cgf.cx","subject":"Re: Error writing loose object on Cygwin","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-07-14T03:34:35Z","receivedAt":"2006-07-14T03:34:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christopher Faylor <me@cgf.cx> wrote:\n> On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:\n> >Shawn Pearce <spearce@spearce.org> writes:\n> >\n> >> Has anyone else seen this type of behavior before?  Any suggestions\n> >> on debugging this issue?\n> >\n> >I would suggest raising this (politely) to Cygwin people.\n> \n> I lost the thread here but wasn't this referring to a samba mount?  If so,\n> it would be samba that's returning the wrong \"errno\".\n\nI thought about that but Windows 2000 talking to the same samba\nserver issues back the correct errno.  Running the exact same Cygwin\nand GIT binaries (we've at least standardized on that).  So it\nseems weird that a samba server is issuing the correct error code\nto a Windows 2000 client but the wrong one to a Windows XP client.\n(In both cases the clients are accessing directories on the same\nfilesystem on the UNIX server.)\n\n-- \nShawn.\n"},{"id":"23800","messageId":"20060714052410.GA19680@trixie.casa.cgf.cx","threadId":"4858","inReplyTo":"20060714033435.GA1508@spearce.org","subject":"Re: Error writing loose object on Cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-07-14T05:24:10Z","receivedAt":"2006-07-14T05:24:10Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jul 13, 2006 at 11:34:35PM -0400, Shawn Pearce wrote:\n>Christopher Faylor <me@cgf.cx> wrote:\n>> On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:\n>> >Shawn Pearce <spearce@spearce.org> writes:\n>> >\n>> >> Has anyone else seen this type of behavior before?  Any suggestions\n>> >> on debugging this issue?\n>> >\n>> >I would suggest raising this (politely) to Cygwin people.\n>> \n>> I lost the thread here but wasn't this referring to a samba mount?  If so,\n>> it would be samba that's returning the wrong \"errno\".\n>\n>I thought about that but Windows 2000 talking to the same samba\n>server issues back the correct errno.  Running the exact same Cygwin\n>and GIT binaries (we've at least standardized on that).  So it\n>seems weird that a samba server is issuing the correct error code\n>to a Windows 2000 client but the wrong one to a Windows XP client.\n>(In both cases the clients are accessing directories on the same\n>filesystem on the UNIX server.)\n\nIt's entirely possible that samba is behaving differently with different\nversions of windows.  OTOH, I believe that EACCES is the catch-all for\nwindows errors when translating into errnos so possibly it is an\nuncaught error translation.\n\nIf you have the inclination and time, if you could run the session\nunder strace:  \"strace -o strace.out git ...\",d snip twenty or\nthirty lines on each side of the place where the the errno translation\nis happening, and send it to the cygwin list at cygwin at cygwin \nmaybe something will be obvious.\n\nNote that cygwin's strace is not anything like any other strace and\nis quite a bit more wordy so, this file will be pretty large.  That's\nwhy I ask for some careful editing before sending it to the mailing\nlist.  The errno number for EACCES on cygwin is 13.\n\ncgf\n"},{"id":"23801","messageId":"Pine.LNX.4.64.0607132217360.5623@g5.osdl.org","threadId":"4858","inReplyTo":"20060714033435.GA1508@spearce.org","subject":"Re: Error writing loose object on Cygwin","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-14T05:26:33Z","receivedAt":"2006-07-14T05:26:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 13 Jul 2006, Shawn Pearce wrote:\n> \n> I thought about that but Windows 2000 talking to the same samba\n> server issues back the correct errno.  Running the exact same Cygwin\n> and GIT binaries (we've at least standardized on that).  So it\n> seems weird that a samba server is issuing the correct error code\n> to a Windows 2000 client but the wrong one to a Windows XP client.\n\nThe samba connection protocol is fairly involved, and it will, as far as I \nknow, do a variety of \"negotiation\" of capabilities of both ends. What a \nW2000 client does can very possibly be very different from what a WXP \nclient does, which in turn is certainly going to be different from a W98 \nclient. It will simply talk a different version of the protocol.\n\nI am also told that the error codes actually differ between different \nversions of the samba protocol - not in the sense that different events \ngenerate different error codes, but that the _same_ error (say \"ENOENT\") \nis actually represented wioth different numbering in \"old Windows SMB\" and \n\"new windows SMB\".\n\nI don't know the details, and may have gotten them wrong, but the point \nit, is't not at all impossible that the exact same version of Samba on the \nserver will negotiate a different protocol because the client OS is \ndifferent, and even though the Cygwin libraries and git binaries are the \nexact same libraries/binaries, they might get different error codes from \nthe same system call.\n\n(This may also explain why there are two \"samba clients\" in the kernel: \nthe CONFIG_SMB and CONFIG_CIFS. CIFS is the \"new version SMB\", and the \nCIFS client currently doesn't even understand the old version - so you \nmight use SMB for old servers, and CIFS for new servers)\n\nThat said, I thought W2000 and WXP both negotiated the \"new\" protocol, but \nthere are probably config details even within that one..\n\n\t\tLinus\n"}]}