{"thread":{"id":"25765","subject":"Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","startedAt":"2010-11-17T06:24:04Z","lastAt":"2010-11-18T20:36:17Z","messageCount":8,"participants":["Albert Strasheim","Matthijs Kooijman","Santi Béjar","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"156031","messageId":"AANLkTi=UPWTeZP9uF+FGtsSs7wH3AmwdeLtsPJQnKvez@mail.gmail.com","threadId":"25765","inReplyTo":null,"subject":"Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Albert Strasheim","fromEmail":"fullung@gmail.com","sentAt":"2010-11-17T06:24:04Z","receivedAt":"2010-11-17T06:24:04Z","isPatch":false,"sender":{"key":"fullung@gmail.com","avatar":null},"body":"Hello all\n\nI'm trying to use git to version all the configuration files on a server:\n\nsu\ncd /\ngit init\ncd /\ntouch k\ngit add k #this works\ncd /etc\ngit add hosts\n\nThis fails with:\n\nfatal: Unable to create '//etc/.git/index.lock': No such file or directory\n\nI'm running git-1.7.3.2-1.fc14.x86_64.\n\nIs there any way to convince git to work in this scenario?\n\nRegards\n\nAlbert\n"},{"id":"156042","messageId":"20101117112042.GX22067@login.drsnuggles.stderr.nl","threadId":"25765","inReplyTo":"AANLkTi=UPWTeZP9uF+FGtsSs7wH3AmwdeLtsPJQnKvez@mail.gmail.com","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Matthijs Kooijman","fromEmail":"matthijs@stdin.nl","sentAt":"2010-11-17T11:20:42Z","receivedAt":"2010-11-17T11:20:42Z","isPatch":false,"sender":{"key":"matthijs@stdin.nl","avatar":"https://avatars.githubusercontent.com/u/194491?v=4"},"body":"Hey,\n\n> su\n> cd /\n> git init\n\nI've been using git for exactly this purpose succesfully for a while now\n(git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian\ntesting). The only problem I've found was that, with the former version,\na lot of operations need to happen while the current dir is /, otherwise\nit wouldn't find the git repository properly (or do other weird stuff).\nThis problem was gone in the latter version.\n\n> fatal: Unable to create '//etc/.git/index.lock': No such file or directory\n\nThis sounds like git assumes /etc/.git exists, but it really doesn't.\nNot sure why that happens.\n\nGr.\n\nMatthijs\n"},{"id":"156104","messageId":"20101118155211.GE22067@login.drsnuggles.stderr.nl","threadId":"25765","inReplyTo":"20101117112042.GX22067@login.drsnuggles.stderr.nl","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Matthijs Kooijman","fromEmail":"matthijs@stdin.nl","sentAt":"2010-11-18T15:52:11Z","receivedAt":"2010-11-18T15:52:11Z","isPatch":false,"sender":{"key":"matthijs@stdin.nl","avatar":"https://avatars.githubusercontent.com/u/194491?v=4"},"body":"Hi all,\n\n> I've been using git for exactly this purpose succesfully for a while now\n> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian\n> testing).\nComing back to the testing machine I was using this on, I see this\nproblem as well now. I'm pretty sure it wasn't there before, which would\nmean it was introduced by a recent upgrade.\n\nChecking the logs shows that I was running 1.7.1 before, and now 1.7.2.3\nis broken. Downgrading to 1.7.1 indeed removes the problem.\n\nI've rummaged around in the source a bit, haven't found the cause yet\n(and I'm out of time now).\n\nThe issue also still occurs with a fairly recent git master (ca209065f:\ncompletion: fix zsh check under bash with 'set -u').\n\nGr.\n\nMatthijs\n"},{"id":"156105","messageId":"AANLkTikbb-PaZoWG4yCtpmMnU-PQiO0wtaXGT+KReOto@mail.gmail.com","threadId":"25765","inReplyTo":"20101118155211.GE22067@login.drsnuggles.stderr.nl","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-11-18T16:00:10Z","receivedAt":"2010-11-18T16:00:10Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Thu, Nov 18, 2010 at 4:52 PM, Matthijs Kooijman <matthijs@stdin.nl> wrote:\n> Hi all,\n>\n>> I've been using git for exactly this purpose succesfully for a while now\n>> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian\n>> testing).\n> Coming back to the testing machine I was using this on, I see this\n> problem as well now. I'm pretty sure it wasn't there before, which would\n> mean it was introduced by a recent upgrade.\n>\n> Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3\n> is broken. Downgrading to 1.7.1 indeed removes the problem.\n>\n> I've rummaged around in the source a bit, haven't found the cause yet\n> (and I'm out of time now).\n\nAlternatively, you could try to bisect, with \"git bisect\", between\nthese two commits, 1.7.2.3=bad and 1.7.1=good. It is roughly 10 steps.\n\nHTH,\nSanti\n"},{"id":"156106","messageId":"AANLkTi=mf_1HaJ0qZJ4nG1=zti9CJdTZHAfhLayR4FRS@mail.gmail.com","threadId":"25765","inReplyTo":"20101118155211.GE22067@login.drsnuggles.stderr.nl","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-18T16:07:39Z","receivedAt":"2010-11-18T16:07:39Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Nov 18, 2010 at 10:52 PM, Matthijs Kooijman <matthijs@stdin.nl> wrote:\n> Hi all,\n>\n>> I've been using git for exactly this purpose succesfully for a while now\n>> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian\n>> testing).\n> Coming back to the testing machine I was using this on, I see this\n> problem as well now. I'm pretty sure it wasn't there before, which would\n> mean it was introduced by a recent upgrade.\n>\n> Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3\n> is broken. Downgrading to 1.7.1 indeed removes the problem.\n>\n> I've rummaged around in the source a bit, haven't found the cause yet\n> (and I'm out of time now).\n>\n> The issue also still occurs with a fairly recent git master (ca209065f:\n> completion: fix zsh check under bash with 'set -u').\n\nYou may be interested in 72ec8ba (Support working directory located at\nroot - 2010-02-14). t1509 reports the breakages. Unfortunately this\nkind of tests can't be run automatically\n-- \nDuy\n"},{"id":"156108","messageId":"AANLkTin6vir9UT9c4-9ArNvFHNdHiDiXMtXKRUMoExho@mail.gmail.com","threadId":"25765","inReplyTo":"AANLkTi=mf_1HaJ0qZJ4nG1=zti9CJdTZHAfhLayR4FRS@mail.gmail.com","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-18T16:26:38Z","receivedAt":"2010-11-18T16:26:38Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Nov 18, 2010 at 11:07 PM, Nguyen Thai Ngoc Duy\n<pclouds@gmail.com> wrote:\n> On Thu, Nov 18, 2010 at 10:52 PM, Matthijs Kooijman <matthijs@stdin.nl> wrote:\n>> Hi all,\n>>\n>>> I've been using git for exactly this purpose succesfully for a while now\n>>> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian\n>>> testing).\n>> Coming back to the testing machine I was using this on, I see this\n>> problem as well now. I'm pretty sure it wasn't there before, which would\n>> mean it was introduced by a recent upgrade.\n>>\n>> Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3\n>> is broken. Downgrading to 1.7.1 indeed removes the problem.\n>>\n>> I've rummaged around in the source a bit, haven't found the cause yet\n>> (and I'm out of time now).\n>>\n>> The issue also still occurs with a fairly recent git master (ca209065f:\n>> completion: fix zsh check under bash with 'set -u').\n>\n> You may be interested in 72ec8ba (Support working directory located at\n> root - 2010-02-14). t1509 reports the breakages. Unfortunately this\n> kind of tests can't be run automatically\n\nI think 490544b (get_cwd_relative(): do not misinterpret suffix as\nsubdirectory - 2010-05-22) causes it. Haven't fully understood what's\ngoing on in that function though :P\n\nWill look again tomorrow, if nobody beats me to it.\n-- \nDuy\n"},{"id":"156114","messageId":"20101118171751.GG22067@login.drsnuggles.stderr.nl","threadId":"25765","inReplyTo":"AANLkTin6vir9UT9c4-9ArNvFHNdHiDiXMtXKRUMoExho@mail.gmail.com","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Matthijs Kooijman","fromEmail":"matthijs@stdin.nl","sentAt":"2010-11-18T17:17:52Z","receivedAt":"2010-11-18T17:17:52Z","isPatch":false,"sender":{"key":"matthijs@stdin.nl","avatar":"https://avatars.githubusercontent.com/u/194491?v=4"},"body":"Hi Nguyen,\n\n> I think 490544b (get_cwd_relative(): do not misinterpret suffix as\n> subdirectory - 2010-05-22) causes it. Haven't fully understood what's\n> going on in that function though :P\nSeems you're right. I just reverted this commit and the problem seems to\ngo away.\n\nIn case you're investigation, here's the relevant call to\nget_cwd_relative in this case is:\n\nBreakpoint 3, get_relative_cwd (buffer=0x756e20 \"\", size=4096, dir=0x764040 \"/\") at dir.c:944\n\nNot sure what the return value is, that one got optimized out.\n\nGr.\n\nMatthijs\n"},{"id":"156137","messageId":"20101118203617.GH22067@login.drsnuggles.stderr.nl","threadId":"25765","inReplyTo":"20101118171751.GG22067@login.drsnuggles.stderr.nl","subject":"Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory","fromName":"Matthijs Kooijman","fromEmail":"matthijs@stdin.nl","sentAt":"2010-11-18T20:36:17Z","receivedAt":"2010-11-18T20:36:17Z","isPatch":false,"sender":{"key":"matthijs@stdin.nl","avatar":"https://avatars.githubusercontent.com/u/194491?v=4"},"body":"Hi folks,\n\n> > I think 490544b (get_cwd_relative(): do not misinterpret suffix as\n> > subdirectory - 2010-05-22) causes it. Haven't fully understood what's\n> > going on in that function though :P\n> Seems you're right. I just reverted this commit and the problem seems to\n> go away.\nA bit more gdb'ing with -O0, I found the following. get_cwd_relative is\ncalled with dir=\"/\". The cwd is \"/etc\". The stack looks like:\n\n#0  get_relative_cwd (buffer=0x7a44c0 \"/etc\", size=4096, dir=0x7b1041 \"\") at dir.c:961\n#1  0x00000000004dfdf1 in setup_git_directory () at setup.c:612\n#2  0x0000000000404f69 in run_builtin (p=0x75ea10, argc=2, argv=0x7fffffffc918) at git.c:257\n#3  0x00000000004051e3 in handle_internal_command (argc=2, argv=0x7fffffffc918) at git.c:431\n#4  0x000000000040538a in main (argc=2, argv=0x7fffffffc918) at git.c:516\n\nAfter the following code runs:\n\n    while (*dir && *dir == *cwd) {\n\t    dir++; \n\t    cwd++;\n    }\n\nI have dir=\"\" and cwd=\"etc\". Then the following code runs:\n\n    switch (*cwd) {\n    case '\\0':\n\t    return cwd;\n    case '/':\n\t    return cwd + 1;\n    default:\n\t    return NULL;\n    }\n\nSince *cwd='e', it returns NULL.\n\nThe old code (before 490544b) was:\n\n   if (*cwd == '/')\n\t   return cwd + 1;\n   return cwd;\n\nSo this would return \"etc\".\n\n\nSo, that's what is happens. I think this happens because\nget_relative_cwd expects dir to not contain a trailing slash. Normally,\nthere is no trailing slash, but in the special case of dir=\"/\" there is\n(sort of) a trailing slash.\n\nI'm not completely sure how to fix this. Looking at 72ec8ba (Support\nworking directory located at root - 2010-02-14), perhaps something like\nthis?\n\ndiff --git a/dir.c b/dir.c\nindex d1e5e5e..5408db9 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -943,6 +943,7 @@ int file_exists(const char *f)\n char *get_relative_cwd(char *buffer, int size, const char *dir)\n {\n        char *cwd = buffer;\n+       size_t len, root_len;\n \n        if (!dir)\n                return NULL;\n@@ -952,6 +953,15 @@ char *get_relative_cwd(char *buffer, int size, const char *dir)\n        if (!is_absolute_path(dir))\n                dir = make_absolute_path(dir);\n \n+       len = strlen(dir);\n+       root_len = offset_1st_component(dir);\n+\n+       if (root_len >= len) {\n+           /* dir is the filesystem root, so the cwd is always inside */\n+           root_len = offset_1st_component(cwd);\n+           return cwd + root_len;\n+       }\n+\n        while (*dir && *dir == *cwd) {\n                dir++;\n                cwd++;\n\nI'm not sure how this stuff really works, though. I think this works for *nix,\nbut I'm unsure about Windows.\n\nGr.\n\nMatthijs\n"}]}