Versioning configuration files on a server: fatal: Unable to create '//etc/.git/index.lock': No such file or directory

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

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

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

On Thu, Nov 18, 2010 at 4:52 PM, Matthijs Kooijman [off-list ref] wrote:

Hi all,

quoted

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

On Thu, Nov 18, 2010 at 10:52 PM, Matthijs Kooijman [off-list ref] wrote:

Hi all,

quoted

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

On Thu, Nov 18, 2010 at 11:07 PM, Nguyen Thai Ngoc Duy
[off-list ref] wrote:

On Thu, Nov 18, 2010 at 10:52 PM, Matthijs Kooijman [off-list ref] wrote:

quoted

Hi all,

quoted

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

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

Hi folks,

quoted

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