# Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory 8 messages from 2010-11-17 to 2010-11-18. Participants: Albert Strasheim, Matthijs Kooijman, Santi Béjar, Nguyen Thai Ngoc Duy. Thread: https://gitlist.dev/t/25765 ## Albert Strasheim, 2010-11-17 06:24 Subject: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: URL: https://gitlist.dev/e/AANLkTi%3DUPWTeZP9uF%2BFGtsSs7wH3AmwdeLtsPJQnKvez%40mail.gmail.com ``` Hello all I'm trying to use git to version all the configuration files on a server: su cd / git init cd / touch k git add k #this works cd /etc git add hosts This fails with: fatal: Unable to create '//etc/.git/index.lock': No such file or directory I'm running git-1.7.3.2-1.fc14.x86_64. Is there any way to convince git to work in this scenario? Regards Albert ``` ## Matthijs Kooijman, 2010-11-17 11:20 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: <20101117112042.GX22067@login.drsnuggles.stderr.nl> URL: https://gitlist.dev/e/20101117112042.GX22067%40login.drsnuggles.stderr.nl In-Reply-To: ``` Hey, > su > cd / > git init I've been using git for exactly this purpose succesfully for a while now (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian testing). The only problem I've found was that, with the former version, a lot of operations need to happen while the current dir is /, otherwise it wouldn't find the git repository properly (or do other weird stuff). This problem was gone in the latter version. > fatal: Unable to create '//etc/.git/index.lock': No such file or directory This sounds like git assumes /etc/.git exists, but it really doesn't. Not sure why that happens. Gr. Matthijs ``` ## Matthijs Kooijman, 2010-11-18 15:52 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: <20101118155211.GE22067@login.drsnuggles.stderr.nl> URL: https://gitlist.dev/e/20101118155211.GE22067%40login.drsnuggles.stderr.nl In-Reply-To: <20101117112042.GX22067@login.drsnuggles.stderr.nl> ``` Hi all, > I've been using git for exactly this purpose succesfully for a while now > (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian > testing). Coming back to the testing machine I was using this on, I see this problem as well now. I'm pretty sure it wasn't there before, which would mean it was introduced by a recent upgrade. Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3 is broken. Downgrading to 1.7.1 indeed removes the problem. I've rummaged around in the source a bit, haven't found the cause yet (and I'm out of time now). The issue also still occurs with a fairly recent git master (ca209065f: completion: fix zsh check under bash with 'set -u'). Gr. Matthijs ``` ## Santi Béjar, 2010-11-18 16:00 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: URL: https://gitlist.dev/e/AANLkTikbb-PaZoWG4yCtpmMnU-PQiO0wtaXGT%2BKReOto%40mail.gmail.com In-Reply-To: <20101118155211.GE22067@login.drsnuggles.stderr.nl> ``` On Thu, Nov 18, 2010 at 4:52 PM, Matthijs Kooijman wrote: > Hi all, > >> I've been using git for exactly this purpose succesfully for a while now >> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian >> testing). > Coming back to the testing machine I was using this on, I see this > problem as well now. I'm pretty sure it wasn't there before, which would > mean it was introduced by a recent upgrade. > > Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3 > is broken. Downgrading to 1.7.1 indeed removes the problem. > > I've rummaged around in the source a bit, haven't found the cause yet > (and I'm out of time now). Alternatively, you could try to bisect, with "git bisect", between these two commits, 1.7.2.3=bad and 1.7.1=good. It is roughly 10 steps. HTH, Santi ``` ## Nguyen Thai Ngoc Duy, 2010-11-18 16:07 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: URL: https://gitlist.dev/e/AANLkTi%3Dmf_1HaJ0qZJ4nG1%3Dzti9CJdTZHAfhLayR4FRS%40mail.gmail.com In-Reply-To: <20101118155211.GE22067@login.drsnuggles.stderr.nl> ``` On Thu, Nov 18, 2010 at 10:52 PM, Matthijs Kooijman wrote: > Hi all, > >> I've been using git for exactly this purpose succesfully for a while now >> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian >> testing). > Coming back to the testing machine I was using this on, I see this > problem as well now. I'm pretty sure it wasn't there before, which would > mean it was introduced by a recent upgrade. > > Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3 > is broken. Downgrading to 1.7.1 indeed removes the problem. > > I've rummaged around in the source a bit, haven't found the cause yet > (and I'm out of time now). > > The issue also still occurs with a fairly recent git master (ca209065f: > completion: fix zsh check under bash with 'set -u'). You may be interested in 72ec8ba (Support working directory located at root - 2010-02-14). t1509 reports the breakages. Unfortunately this kind of tests can't be run automatically -- Duy ``` ## Nguyen Thai Ngoc Duy, 2010-11-18 16:26 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: URL: https://gitlist.dev/e/AANLkTin6vir9UT9c4-9ArNvFHNdHiDiXMtXKRUMoExho%40mail.gmail.com In-Reply-To: ``` On Thu, Nov 18, 2010 at 11:07 PM, Nguyen Thai Ngoc Duy wrote: > On Thu, Nov 18, 2010 at 10:52 PM, Matthijs Kooijman wrote: >> Hi all, >> >>> I've been using git for exactly this purpose succesfully for a while now >>> (git 1.5.6.5 from Debian stable and I think also 1.7.2.3 from Debian >>> testing). >> Coming back to the testing machine I was using this on, I see this >> problem as well now. I'm pretty sure it wasn't there before, which would >> mean it was introduced by a recent upgrade. >> >> Checking the logs shows that I was running 1.7.1 before, and now 1.7.2.3 >> is broken. Downgrading to 1.7.1 indeed removes the problem. >> >> I've rummaged around in the source a bit, haven't found the cause yet >> (and I'm out of time now). >> >> The issue also still occurs with a fairly recent git master (ca209065f: >> completion: fix zsh check under bash with 'set -u'). > > You may be interested in 72ec8ba (Support working directory located at > root - 2010-02-14). t1509 reports the breakages. Unfortunately this > kind of tests can't be run automatically I think 490544b (get_cwd_relative(): do not misinterpret suffix as subdirectory - 2010-05-22) causes it. Haven't fully understood what's going on in that function though :P Will look again tomorrow, if nobody beats me to it. -- Duy ``` ## Matthijs Kooijman, 2010-11-18 17:17 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: <20101118171751.GG22067@login.drsnuggles.stderr.nl> URL: https://gitlist.dev/e/20101118171751.GG22067%40login.drsnuggles.stderr.nl In-Reply-To: ``` Hi Nguyen, > I think 490544b (get_cwd_relative(): do not misinterpret suffix as > subdirectory - 2010-05-22) causes it. Haven't fully understood what's > going on in that function though :P Seems you're right. I just reverted this commit and the problem seems to go away. In case you're investigation, here's the relevant call to get_cwd_relative in this case is: Breakpoint 3, get_relative_cwd (buffer=0x756e20 "", size=4096, dir=0x764040 "/") at dir.c:944 Not sure what the return value is, that one got optimized out. Gr. Matthijs ``` ## Matthijs Kooijman, 2010-11-18 20:36 Subject: Re: Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory Message-ID: <20101118203617.GH22067@login.drsnuggles.stderr.nl> URL: https://gitlist.dev/e/20101118203617.GH22067%40login.drsnuggles.stderr.nl In-Reply-To: <20101118171751.GG22067@login.drsnuggles.stderr.nl> ``` Hi folks, > > I think 490544b (get_cwd_relative(): do not misinterpret suffix as > > subdirectory - 2010-05-22) causes it. Haven't fully understood what's > > going on in that function though :P > Seems you're right. I just reverted this commit and the problem seems to > go away. A bit more gdb'ing with -O0, I found the following. get_cwd_relative is called with dir="/". The cwd is "/etc". The stack looks like: #0 get_relative_cwd (buffer=0x7a44c0 "/etc", size=4096, dir=0x7b1041 "") at dir.c:961 #1 0x00000000004dfdf1 in setup_git_directory () at setup.c:612 #2 0x0000000000404f69 in run_builtin (p=0x75ea10, argc=2, argv=0x7fffffffc918) at git.c:257 #3 0x00000000004051e3 in handle_internal_command (argc=2, argv=0x7fffffffc918) at git.c:431 #4 0x000000000040538a in main (argc=2, argv=0x7fffffffc918) at git.c:516 After the following code runs: while (*dir && *dir == *cwd) { dir++; cwd++; } I have dir="" and cwd="etc". Then the following code runs: switch (*cwd) { case '\0': return cwd; case '/': return cwd + 1; default: return NULL; } Since *cwd='e', it returns NULL. The old code (before 490544b) was: if (*cwd == '/') return cwd + 1; return cwd; So this would return "etc". So, that's what is happens. I think this happens because get_relative_cwd expects dir to not contain a trailing slash. Normally, there is no trailing slash, but in the special case of dir="/" there is (sort of) a trailing slash. I'm not completely sure how to fix this. Looking at 72ec8ba (Support working directory located at root - 2010-02-14), perhaps something like this? diff --git a/dir.c b/dir.c index d1e5e5e..5408db9 100644 --- a/dir.c +++ b/dir.c @@ -943,6 +943,7 @@ int file_exists(const char *f) char *get_relative_cwd(char *buffer, int size, const char *dir) { char *cwd = buffer; + size_t len, root_len; if (!dir) return NULL; @@ -952,6 +953,15 @@ char *get_relative_cwd(char *buffer, int size, const char *dir) if (!is_absolute_path(dir)) dir = make_absolute_path(dir); + len = strlen(dir); + root_len = offset_1st_component(dir); + + if (root_len >= len) { + /* dir is the filesystem root, so the cwd is always inside */ + root_len = offset_1st_component(cwd); + return cwd + root_len; + } + while (*dir && *dir == *cwd) { dir++; cwd++; I'm not sure how this stuff really works, though. I think this works for *nix, but I'm unsure about Windows. Gr. Matthijs ```