Git Cygwin - unable to create any repository - help!

Trying to create a repository under the cygwin install of git, windows XP Pro. I can create the initial repository OK using "git init" and add files using "git add .", but when I come to commit I get the messages:

error: invalid object d9b06fceac52f6c24357e6a7f85c601 088381152 fatal: git-write-tree: error building trees

git-fsck gives me:

notice: HEAD points to an unborn branch (master) notice: No default references missing blob d9b06fceac52f6c24357e6a7f85c601088381152

This is with a simple repository of one directory containing one plain ascii text file with some text in it. I get similar messages, with one missing blob for each file or directory in the project, on more complex projects. At home, I use git under Ubuntu linux and haven't had any such problems.

The git/cygwin install followed the instruction for a cygwin binary installation from the wiki and no problems were reported. I've been unable to find online comments relating to this problem and am stuck.

Any suggestions?

Paul

Paul Umbers, Mon, Jan 14, 2008 18:21:44 +0100:

Is it a "text-mode" mount where your repository is to reside?

The "mount" command tells me everything I have is mounted in binmode. I have used Git on a default cygwin install (win XP pro) before and not had this problem - that's why this is so frustrating. Not sure what changed this time round as I tend to use defaults for most installations.

Are you saying I need to make sure the repository directory is mounted in text-mode (for Windows compatibility)? I just reinstalled cygwin, selecting text-mode as the default. I can create a git repository, but "git add ." returns:

fatal: cannot use /cygdrive/c/test/.git/info/exclude as an exclude file

Paul

 On Jan 14, 2008 1:29 PM, Alex Riesen <raa.lkml@gmail.com> wrote:

Paul Umbers, Mon, Jan 14, 2008 23:21:28 +0100:

Now that's unusual, unless you had "Text Mode" selected in the installer

No, text-mode is definitely wrong for almost anything. It just corrupts data. Try activating binary mode.

I've just completely uninstalled (ie: deleted) and re-installed cygwin, ensuring that bin mode was selected for the install (I'm sure it was before, that's the default). "mount" confirms that everything is mounted in binmode.

Sadly, I still can't commit to a git repository - same problem: every file & directory immediately shows as a "missing blob" after "git add ."

I'll try the same install on my home system (Win XP Home) and see if I get the same problem.

Paul

Paul Umbers, Tue, Jan 15, 2008 16:21:15 +0100:

Ok, so it is a bit more complicated...

Paul Umbers, Mon, Jan 14, 2008 18:21:44 +0100:

Does the object exists at all? Try

    ls -l .git/d9/b06fceac52f6c24357e6a7f85c601088381152

Is it possible to get a hold of this repo (just the .git directly after "git add .")? It would be interesting to see the nature of the corruption.

git ls (see below) returns nothing - it looks like the object doesn't exist at all. I've attached a .zip of the entire test directory (one text file plus .git). This is after "git init" followed by "git add ."

What do you think?

Paul Umbers, Tue, Jan 15, 2008 21:12:45 +0100:

zip is a bit lying: it does not keep the attributes of the files the way cygwin programs see them. For instance, it not known whether the hooks (.git/hooks) where executable at the time.

I think it has failed already at "git add". From looking at the code it is hard for the current git-add (builtin-add.c) to fail silently.

Hmm... What "git version" returns for you? (the .git/config contains filemode=true, which cygwin breaks every time).

Of course, it would be interesting to know if the current git works for you. Or the MinGW port:

    http://code.google.com/p/msysgit/downloads/list

It used to conflict with cygwin, though.

If the current git fails, I'd suggest to instrument write_sha1_file in sha1_file.c and see if it really manages to create temporary file and rename it to sha1 file (that d9/b06fceac52f6c24357e6a7f85c601088381152). I suspect either rename or link failing silently (IOW, it fails to create the new name under objects/d9/ but returns 0(no error) anyway).

Try this ... test.tar (from within cygwin).

On Jan 15, 2008 2:20 PM, Alex Riesen <raa.lkml@gmail.com> wrote:

Paul Umbers, Tue, Jan 15, 2008 22:57:35 +0100:

Ok, nothing suspicios here.

Git version is 1.5.3.8.

On Jan 15, 2008 2:20 PM, Alex Riesen <raa.lkml@gmail.com> wrote:

Paul Umbers, Tue, Jan 15, 2008 22:59:52 +0100:

That's ok too. The git-add is as verbose regarding errors as today.

Next would be to try to recompile git and instrument that file:

Or try the MinGW port

That sha1_file.c above

tisdagen den 15 januari 2008 skrev Paul Umbers:

Git comes with test suite. Try it using make test or

GIT_TEST_OPTS="--debug --verbose" make test

The extra options are there since we expect it to fail.

-- robin

Robin Rosenberg, Wed, Jan 16, 2008 00:02:49 +0100:

He has just the precompiled packages from cygwin

But when compiled, it would be useflul indeed to see how the tests run

OK, I think this worked (I'm a Java man, not C/C++). I downloaded the latest 1.5.3 source from the git repository and ran "make" with GIT_TEST_OPTS="--verbose --debug". Here's the output:

paulumbers@Devteam29 ~/workspace/git/git-1.5.3/t
$ make
*** t0000-basic.sh ***
*   ok 1: .git/objects should be empty after git init in an empty repo.
*   ok 2: .git/objects should have 3 subdirectories.
*   ok 3: git update-index without --add should fail adding.
*   ok 4: git update-index with --add should succeed.
* FAIL 5: writing tree out with git write-tree
        tree=$(git write-tree)
* FAIL 6: validate object ID of a known tree.
        test "$tree" = 7bb943559a305bdd6bdee2cef6e5df2413c3d30a
*   ok 7: git update-index without --remove should fail removing.
*   ok 8: git update-index with --remove should be able to remove.
*   ok 9: git write-tree should be able to write an empty tree.
*   ok 10: validate object ID of a known tree.
*   ok 11: adding various types of objects with git update-index --add.
*   ok 12: showing stage with git ls-files --stage
*   ok 13: validate git ls-files output for a known tree.
* FAIL 14: writing tree out with git write-tree.
        tree=$(git write-tree)
* FAIL 15: validate object ID for a known tree.
        test "$tree" = 087704a96baf1c2d1c869a8b084481e121c88b5b
* FAIL 16: showing tree with git ls-tree
        git ls-tree $tree >current
* FAIL 17: git ls-tree output for a known tree.
        diff current expected
* FAIL 18: showing tree with git ls-tree -r
        git ls-tree -r $tree >current
* FAIL 19: git ls-tree -r output for a known tree.
        diff current expected
* FAIL 20: showing tree with git ls-tree -r -t
        git ls-tree -r -t $tree >current
* FAIL 21: git ls-tree -r output for a known tree.
        diff current expected
* FAIL 22: writing partial tree out with git write-tree --prefix.
        ptree=$(git write-tree --prefix=path3)
* FAIL 23: validate object ID for a known tree.
        test "$ptree" = 21ae8269cacbe57ae09138dcc3a2887f904d02b3
* FAIL 24: writing partial tree out with git write-tree --prefix.
        ptree=$(git write-tree --prefix=path3/subp3)
* FAIL 25: validate object ID for a known tree.
        test "$ptree" = 3c5e5399f3a333eddecce7a9b9465b63f65f51e2
*   ok 26: put invalid objects into the index.
*   ok 27: writing this tree without --missing-ok.
*   ok 28: writing this tree with --missing-ok.
* FAIL 29: git read-tree followed by write-tree should be idempotent.
        git read-tree $tree &&
             test -f .git/index &&
             newtree=$(git write-tree) &&
             test "$newtree" = "$tree"
* FAIL 30: validate git diff-files output for a know cache/work tree state.
        git diff-files >current && diff >/dev/null -b current expected
*   ok 31: git update-index --refresh should succeed.
*   ok 32: no diff after checkout and git update-index --refresh.
* FAIL 33: git commit-tree records the correct tree in a commit.
        commit0=$(echo NO | git commit-tree $P) &&
             tree=$(git show --pretty=raw $commit0 |
                 sed -n -e "s/^tree //p" -e "/^author /q") &&
             test "z$tree" = "z$P"
* FAIL 34: git commit-tree records the correct parent in a commit.
        commit1=$(echo NO | git commit-tree $P -p $commit0) &&
             parent=$(git show --pretty=raw $commit1 |
                 sed -n -e "s/^parent //p" -e "/^author /q") &&
             test "z$commit0" = "z$parent"
* FAIL 35: git commit-tree omits duplicated parent in a commit.
        commit2=$(echo NO | git commit-tree $P -p $commit0 -p $commit0) &&
             parent=$(git show --pretty=raw $commit2 |
                 sed -n -e "s/^parent //p" -e "/^author /q" |
                 sort -u) &&
             test "z$commit0" = "z$parent" &&
             numparent=$(git show --pretty=raw $commit2 |
                 sed -n -e "s/^parent //p" -e "/^author /q" |
                 wc -l) &&
             test $numparent = 1
*   ok 36: update-index D/F conflict
* FAIL 37: absolute path works as expected

                mkdir first &&
                ln -s ../.git first/.git &&
                mkdir second &&
                ln -s ../first second/other &&
                mkdir third &&
                dir="$(cd .git; pwd -P)" &&
                dir2=third/../second/other/.git &&
                test "$dir" = "$(test-absolute-path $dir2)" &&
                file="$dir"/index &&
                test "$file" = "$(test-absolute-path $dir2/index)" &&
                ln -s ../first/file .git/syml &&
                sym="$(cd first; pwd -P)"/file &&
                test "$sym" = "$(test-absolute-path $dir2/syml)"

* failed 20 among 37 test(s)
make: *** [t0000-basic.sh] Error 1

paulumbers@Devteam29 ~/workspace/git/git-1.5.3/t $ make -v -d GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This program built for i686-pc-cygwin

paulumbers@Devteam29 ~/workspace/git/git-1.5.3/t $ export GIT_TEST_OPTS="--verbose --debug"

paulumbers@Devteam29 ~/workspace/git/git-1.5.3/t
$ make
*** t0000-basic.sh ***
* expecting success: cmp -s /dev/null should-be-empty
*   ok 1: .git/objects should be empty after git init in an empty repo.

* expecting success: test $(wc -l < full-of-directories) = 3
*   ok 2: .git/objects should have 3 subdirectories.

* expecting failure: git update-index should-be-empty
error: should-be-empty: cannot add to the index - missing --add option?
fatal: Unable to process path should-be-empty
*   ok 3: git update-index without --add should fail adding.

* expecting success: git update-index --add should-be-empty
*   ok 4: git update-index with --add should succeed.

* expecting success: tree=$(git write-tree)
error: invalid object e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
fatal: git-write-tree: error building trees
* FAIL 5: writing tree out with git write-tree
        tree=$(git write-tree)

* expecting success: test "$tree" = 7bb943559a305bdd6bdee2cef6e5df2413c3d30a
* FAIL 6: validate object ID of a known tree.
        test "$tree" = 7bb943559a305bdd6bdee2cef6e5df2413c3d30a

* expecting failure: git update-index should-be-empty
error: should-be-empty: does not exist and --remove not passed
fatal: Unable to process path should-be-empty
*   ok 7: git update-index without --remove should fail removing.

* expecting success: git update-index --remove should-be-empty
*   ok 8: git update-index with --remove should be able to remove.

* expecting success: tree=$(git write-tree)
*   ok 9: git write-tree should be able to write an empty tree.

* expecting success: test "$tree" = 4b825dc642cb6eb9a060e54bf8d69288fbee4904
*   ok 10: validate object ID of a known tree.

* expecting success: find path* ! -type d -print | xargs git update-index --add
*   ok 11: adding various types of objects with git update-index --add.

* expecting success: git ls-files --stage >current
*   ok 12: showing stage with git ls-files --stage

* expecting success: diff current expected
*   ok 13: validate git ls-files output for a known tree.

* expecting success: tree=$(git write-tree)
error: invalid object 3feff949ed00a62d9f7af97c15cd8a30595e7ac7
fatal: git-write-tree: error building trees
* FAIL 14: writing tree out with git write-tree.
        tree=$(git write-tree)

* expecting success: test "$tree" = 087704a96baf1c2d1c869a8b084481e121c88b5b
* FAIL 15: validate object ID for a known tree.
        test "$tree" = 087704a96baf1c2d1c869a8b084481e121c88b5b

* expecting success: git ls-tree $tree >current
usage: git-ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only]
[--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]
* FAIL 16: showing tree with git ls-tree
        git ls-tree $tree >current

* expecting success: diff current expected
0a1,4

* FAIL 17: git ls-tree output for a known tree.
        diff current expected

* expecting success: git ls-tree -r $tree >current
usage: git-ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only]
[--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]
* FAIL 18: showing tree with git ls-tree -r
        git ls-tree -r $tree >current

* expecting success: diff current expected
0a1,8

* FAIL 19: git ls-tree -r output for a known tree.
        diff current expected

* expecting success: git ls-tree -r -t $tree >current
usage: git-ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only]
[--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]
* FAIL 20: showing tree with git ls-tree -r -t
        git ls-tree -r -t $tree >current

* expecting success: diff current expected
0a1,11

* FAIL 21: git ls-tree -r output for a known tree.
        diff current expected

* expecting success: ptree=$(git write-tree --prefix=path3)
error: invalid object 3feff949ed00a62d9f7af97c15cd8a30595e7ac7
fatal: git-write-tree: error building trees
* FAIL 22: writing partial tree out with git write-tree --prefix.
        ptree=$(git write-tree --prefix=path3)

* expecting success: test "$ptree" = 21ae8269cacbe57ae09138dcc3a2887f904d02b3
* FAIL 23: validate object ID for a known tree.
        test "$ptree" = 21ae8269cacbe57ae09138dcc3a2887f904d02b3

* expecting success: ptree=$(git write-tree --prefix=path3/subp3)
error: invalid object 3feff949ed00a62d9f7af97c15cd8a30595e7ac7
fatal: git-write-tree: error building trees
* FAIL 24: writing partial tree out with git write-tree --prefix.
        ptree=$(git write-tree --prefix=path3/subp3)

* expecting success: test "$ptree" = 3c5e5399f3a333eddecce7a9b9465b63f65f51e2
* FAIL 25: validate object ID for a known tree.
        test "$ptree" = 3c5e5399f3a333eddecce7a9b9465b63f65f51e2

* expecting success: git update-index --index-info < badobjects
*   ok 26: put invalid objects into the index.

* expecting failure: git write-tree
error: invalid object 1000000000000000000000000000000000000000
fatal: git-write-tree: error building trees
*   ok 27: writing this tree without --missing-ok.

* expecting success: git write-tree --missing-ok
851a367613bb6e1f0b2b518323eafed530b5b4c4
*   ok 28: writing this tree with --missing-ok.

* expecting success: git read-tree $tree &&
     test -f .git/index &&
     newtree=$(git write-tree) &&
     test "$newtree" = "$tree"
* FAIL 29: git read-tree followed by write-tree should be idempotent.
        git read-tree $tree &&
             test -f .git/index &&
             newtree=$(git write-tree) &&
             test "$newtree" = "$tree"

* expecting success: git diff-files >current && diff >/dev/null -b
current expected
* FAIL 30: validate git diff-files output for a know cache/work tree state.
        git diff-files >current && diff >/dev/null -b current expected

* expecting success: git update-index --refresh
*   ok 31: git update-index --refresh should succeed.

* expecting success: git diff-files >current && cmp -s current /dev/null
*   ok 32: no diff after checkout and git update-index --refresh.

* expecting success: commit0=$(echo NO | git commit-tree $P) &&
     tree=$(git show --pretty=raw $commit0 |
         sed -n -e "s/^tree //p" -e "/^author /q") &&
     test "z$tree" = "z$P"
error: unable to find 087704a96baf1c2d1c869a8b084481e121c88b5b
fatal: 087704a96baf1c2d1c869a8b084481e121c88b5b is not a valid object
* FAIL 33: git commit-tree records the correct tree in a commit.
        commit0=$(echo NO | git commit-tree $P) &&
             tree=$(git show --pretty=raw $commit0 |
                 sed -n -e "s/^tree //p" -e "/^author /q") &&
             test "z$tree" = "z$P"

* expecting success: commit1=$(echo NO | git commit-tree $P -p $commit0) &&
     parent=$(git show --pretty=raw $commit1 |
         sed -n -e "s/^parent //p" -e "/^author /q") &&
     test "z$commit0" = "z$parent"
error: unable to find 087704a96baf1c2d1c869a8b084481e121c88b5b
fatal: 087704a96baf1c2d1c869a8b084481e121c88b5b is not a valid object
* FAIL 34: git commit-tree records the correct parent in a commit.
        commit1=$(echo NO | git commit-tree $P -p $commit0) &&
             parent=$(git show --pretty=raw $commit1 |
                 sed -n -e "s/^parent //p" -e "/^author /q") &&
             test "z$commit0" = "z$parent"

* expecting success: commit2=$(echo NO | git commit-tree $P -p
$commit0 -p $commit0) &&
     parent=$(git show --pretty=raw $commit2 |
         sed -n -e "s/^parent //p" -e "/^author /q" |
         sort -u) &&
     test "z$commit0" = "z$parent" &&
     numparent=$(git show --pretty=raw $commit2 |
         sed -n -e "s/^parent //p" -e "/^author /q" |
         wc -l) &&
     test $numparent = 1
error: unable to find 087704a96baf1c2d1c869a8b084481e121c88b5b
fatal: 087704a96baf1c2d1c869a8b084481e121c88b5b is not a valid object
* FAIL 35: git commit-tree omits duplicated parent in a commit.
        commit2=$(echo NO | git commit-tree $P -p $commit0 -p $commit0) &&
             parent=$(git show --pretty=raw $commit2 |
                 sed -n -e "s/^parent //p" -e "/^author /q" |
                 sort -u) &&
             test "z$commit0" = "z$parent" &&
             numparent=$(git show --pretty=raw $commit2 |
                 sed -n -e "s/^parent //p" -e "/^author /q" |
                 wc -l) &&
             test $numparent = 1

* expecting success:
        mv path0 tmp &&
        mv path2 path0 &&
        mv tmp path2 &&
        git update-index --add --replace path2 path0/file2 &&
        numpath0=$(git ls-files path0 | wc -l) &&
        test $numpath0 = 1

*   ok 36: update-index D/F conflict

* expecting success:
        mkdir first &&
        ln -s ../.git first/.git &&
        mkdir second &&
        ln -s ../first second/other &&
        mkdir third &&
        dir="$(cd .git; pwd -P)" &&
        dir2=third/../second/other/.git &&
        test "$dir" = "$(test-absolute-path $dir2)" &&
        file="$dir"/index &&
        test "$file" = "$(test-absolute-path $dir2/index)" &&
        ln -s ../first/file .git/syml &&
        sym="$(cd first; pwd -P)"/file &&
        test "$sym" = "$(test-absolute-path $dir2/syml)"

* FAIL 37: absolute path works as expected

                mkdir first &&
                ln -s ../.git first/.git &&
                mkdir second &&
                ln -s ../first second/other &&
                mkdir third &&
                dir="$(cd .git; pwd -P)" &&
                dir2=third/../second/other/.git &&
                test "$dir" = "$(test-absolute-path $dir2)" &&
                file="$dir"/index &&
                test "$file" = "$(test-absolute-path $dir2/index)" &&
                ln -s ../first/file .git/syml &&
                sym="$(cd first; pwd -P)"/file &&
                test "$sym" = "$(test-absolute-path $dir2/syml)"

* failed 20 among 37 test(s)
make: *** [t0000-basic.sh] Error 1

"Paul Umbers" <paul.umbers@gmail.com> writes:

Often the first error is the most interesting, as your build is failing the most basic operation (like creating a tree), and later parts of the test uses the tree to validate other aspects of your build.

After seeing the above error, running the test with -i (stop immediately on failure):

	$ cd t
        $ sh -x ./t0000-basic.sh -i -v

and looking at the exact command that fails is the usual approach for debugging something like this. During that debugging session, the contents of the directory t/trash (which is where the test script runs) left by the failed test is what we often do.

Tried Junio's latest suggestion. The resulting output and contents of the trash are attached as a tar.gz. Thanks for all your help guys, I'm sorry I can't contribute more but as I mentioned, I'm nowhere near proficient in c/c++ or the internals of Git.

Paul

On Jan 16, 2008 10:55 AM, Junio C Hamano <gitster@pobox.com> wrote:

Paul Umbers, Wed, Jan 16, 2008 19:10:43 +0100:

Well, either it didn't work or you omited something critical (like stderr):

    * expecting success: tree=$(git write-tree)
    * FAIL 5: writing tree out with git write-tree
	    tree=$(git write-tree)

that is too short. All the traces missing. Could you please retry with

    sh -x ./t0000-basic.sh -d -v -i &> test_results.txt

? If that is what you actually did, I suspect you have a very broken shell installed. Could you check if you have bash (bash --version) and try it instead of "sh"?

Done. The cygwin install is the standard, all-defaults install (and I've done it 5 times now). I've attached a tar.gz with the test results run under sh and bash. Hope that helps.

On Jan 16, 2008 11:38 AM, Alex Riesen <raa.lkml@gmail.com> wrote:

Paul Umbers, Wed, Jan 16, 2008 16:42:46 +0100:

...

Ok, since you managed to compile it, could you please try to strace git-add? Cygwins strace is a bit unusual, but strace --help can provide enough information to configure it to trace filesystem operations.

In the top-level of Git source directory:

    $ uname -a > somefile
    $ strace -o log -f -m syscall ./git --exec-path=$(pwd) add somefile
    $ git ls-files -s somefile

or

    $ strace -o log -f -m syscall ./git --exec-path=$(pwd) hash-object somefile

Than check if the sha1file is missing and send in the log.

Latest output, log file attached:

paulumbers@Devteam29 ~/workspace/git/git-1.5.3 $ uname -a > somefile

paulumbers@Devteam29 ~/workspace/git/git-1.5.3 $ git init Initialized empty Git repository in .git/

paulumbers@Devteam29 ~/workspace/git/git-1.5.3 $ strace -o log -f -m syscall ./git --exec-path=$(pwd) add somefile

paulumbers@Devteam29 ~/workspace/git/git-1.5.3 $ git ls-files -s somefile 100644 2ed63d326ffdb2fd4b703780f4d61f1893cac63b 0 somefile

Checking .git/objects/2e ... there is no sha1 file

Paul Umbers, Wed, Jan 16, 2008 19:48:28 +0100:

Hmm... Could you try to create a repo so that the whole path contains no whitespace? Something like "c:/tmp/mydir". Just a suggestion, I am still inspecting your log...

Paul Umbers, Wed, Jan 16, 2008 19:48:28 +0100:

Could you please retry with "-m all"? "-m syscall" is not what one might expect, its some tracing of cygwin and not enough at that.

Here's the log from the latest strace.

On Jan 16, 2008 12:17 PM, Alex Riesen <raa.lkml@gmail.com> wrote:

Paul Umbers, Wed, Jan 16, 2008 22:44:10 +0100:

Something is fishy here (aside from the horrible selection of information in the trace output):

   56 1151793 [main] git 3244 symlink_info::check: 0 = symlink.check (c:\workspace\git\git-1.5.3\.git\objects\2e, 0x22BBE0) (0x2A)
   58 1151851 [main] git 3244 path_conv::check: this->path(c:\workspace\git\git-1.5.3\.git\objects\2e\d63d326ffdb2fd4b703780f4d61f1893cac63b), has_acls(1)
   65 1151916 [main] git 3244 fhandler_base::open: (c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L, 0x110000)
  206 1152122 [main] git 3244 fhandler_base::set_flags: flags 0x110000, supplied_bin 0x10000
   76 1152198 [main] git 3244 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x10000
  308 1152506 [main] git 3244 fhandler_base::set_flags: filemode set to binary
  146 1152652 [main] git 3244 fhandler_base::open: 0 = NtCreateFile (0x6D0, 20100, c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L, io, NULL, 0, 7, 1, 4400, NULL, 0)
   74 1152726 [main] git 3244 fhandler_base::open: 1 = fhandler_base::open (c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L, 0x110000)
  105 1152831 [main] git 3244 fhandler_base::open_fs: 1 = fhandler_disk_file::open (c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L, 0x10000)
 5915 1158746 [main] git 3244 fhandler_disk_file::link: CreateHardLinkA failed
   94 1158840 [main] git 3244 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.5.25-7/winsup/cygwin/fhandler_disk_file.cc:893 windows error 183
   72 1158912 [main] git 3244 geterrno_from_win_error: windows error 183 == errno 17
   64 1158976 [main] git 3244 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):310 val 17
   65 1159041 [main] git 3244 fhandler_base::close: closing '/cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L' handle 0x6D0
  124 1159165 [main] git 3244 link: -1 = link (/cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L, /cygdrive/c/workspace/git/git-1.5.3/.git/objects/2e/d63d326ffdb2fd4b703780f4d61f1893cac63b)
   87 1159252 [main] git 3244 normalize_posix_path: src /cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L
   94 1159346 [main] git 3244 normalize_posix_path: /cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L = normalize_posix_path (/cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L)
   65 1159411 [main] git 3244 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L)
  104 1159515 [main] git 3244 mount_info::cygdrive_win32_path: src '/cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L', dst 'c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L'
   73 1159588 [main] git 3244 set_flags: flags: binary (0x2)
   62 1159650 [main] git 3244 mount_info::conv_to_win32_path: src_path /cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L, dst c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L, flags 0x2A, rc 0
  130 1159780 [main] git 3244 symlink_info::check: not a symlink
   66 1159846 [main] git 3244 symlink_info::check: 0 = symlink.check (c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L, 0x22C110) (0x2A)
   67 1159913 [main] git 3244 path_conv::check: this->path(c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L), has_acls(1)
   64 1159977 [main] git 3244 unlink: _unlink (c:\workspace\git\git-1.5.3\.git\objects\tmp_obj_rOxD3L)
  763 1160740 [main] git 3244 unlink: 1 = CloseHandle (0x6D0)
  144 1160884 [main] git 3244 unlink: CreateFile (FILE_FLAG_DELETE_ON_CLOSE) succeeded
   66 1160950 [main] git 3244 unlink: 0 = unlink (/cygdrive/c/workspace/git/git-1.5.3/.git/objects/tmp_obj_rOxD3L)

Could you locate move_temp_to_file and make it unconditionally rename the tempfile into target sha1 file? It should become something like that:

int move_temp_to_file(const char *tmpfile, const char *filename)
{
	int ret = link_temp_to_file(tmpfile, filename);

	/*
	 * Coda hack - coda doesn't like cross-directory links,
	 * so we fall back to a rename, which will mean that it
	 * won't be able to check collisions, but that's not a
	 * big deal.
	 *
	 * The same holds for FAT formatted media.
	 *
	 * When this succeeds, we just return 0. We have nothing
	 * left to unlink.
	 */
	if (!rename(tmpfile, filename))
		return 0;
	ret = errno;
	unlink(tmpfile);
	if (ret) {
		if (ret != EEXIST) {
			return error("unable to write sha1 filename %s: %s\n", filename, strerror(ret));
		}
		/* FIXME!!! Collision check here ? */
		return error("failed to write sha1 filename %s: %s\n", filename, strerror(ret));
	}

	return 0;
}

Does someone know, why this function seem to return 0 (success) on something which looks like an SHA1 collision? And destroy the tempfile, even though it is not moved anywhere.

Made the changes you specify below & re-ran "make install". Attached is the log from the latest strace.

Incidentally, I've tried this on two other machines at work with the same results. The steps to reproduce are annoyingly simple: download cygwin installer & execute (accept all defaults), select the packages specified for the binary windows install on the git wiki, try to create a git repository and add files. Frustrating - especially since my desktop at my last job worked just fine.

Paul

On Jan 16, 2008 4:45 PM, Alex Riesen <raa.lkml@gmail.com> wrote: SNIP

On Thu, 17 Jan 2008, Paul Umbers wrote:

Is there perhaps some odd virus scanner or something that interferes with filesystem operations? It sounds like you have consistent problems on *some* machines, but others cannot reproduce them, which makes me wonder if there is some setup issue. Maybe your company machines have some DLL or something that interferes subtly with cygwin.

(Eg there might be another cygwin install hidden off somewhere?)

The "virus scanner" thing was just a random thought, but under windows it's not unheard of to have things that intercept filesystem accesses for things like that. Virus scanners, "security features", rootkits from Sony or other sources of trouble etc - you name it.

That kind of environmental difference would explain why you didn't see it on another machine, and why others seem to not be able to reproduce it either.

			Linus

Hi,

On Thu, 17 Jan 2008, Linus Torvalds wrote:

Or that Logitech Abomination of an "Updater service"? On one of my machines, I had tons of problems before just uninstalling those "drivers".

Ciao, Dscho

Quite possibly. We have Embassy Trust Suite and Symantec Endpoint Security installed on all our work machines, while I use ClamWin at home and don't have this problem. The symptoms would indicate that it is an environmental difference and this is certainly a candidate.

I've disabled as many of the Symantec features as I can without uninstalling it (which I don't have permissions to do), and I still get the same problem. So, if it is Symantec then it's at a level deeper than I can go. Not sure about the Embassy suite, I'll have a play and see what I can find but it's tricky as the sysadmins here don't like us developer-types playing with security settings on our machines. Go figure.

I've also tried a complete (including registry keys) reinstall of cygwin (as per Nicholas' email) and still have the problem. I'll try a summary posting to the cygwin group as suggested to see if they know of anything over there. If there's anything else I can do in the meantime, please let me know. I'll be closing my eyes real tight and hoping that next time I open them I have a Linux desktop in front of me :-)

Thanks for all your help guys, Paul

On Jan 17, 2008 11:51 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

On Thu, 17 Jan 2008, Paul Umbers wrote:

That's it.

Do a google for 

	Embassy Trust Suite cygwin

and revel in all the reports of problems with cygwin with that thing installed.

See for example Dave Korn at:

	http://www.cygwin.com/ml/cygwin/2007-05/msg00132.html

or this on:

	http://www.cygwin.com/ml/cygwin-talk/2007-q1/msg00270.html
	http://sourceware.org/ml/cygwin/2006-05/msg00856.html

so I'm pretty sure that's it.

Ahh, the joys of Windows.

Btw, did you ever test the msys version of git

	http://code.google.com/p/msysgit/

since I suspect that it's likely to not just be faster, but also more robust, since there is a much thinner layer between git and windows (and thus hopefully many fewer complex dependencies that can go wrong).

			Linus
		

Linus Torvalds a écrit :

Well don't blame windows for every problem in the world ;) ... in this specific case I think it is more like a stupid anti-virus problem. It turn out that those pieces of software are probably the most buggy one and at the same time just useless!

Pascal.

Hi,

On Thu, 17 Jan 2008, Pascal Obry wrote:

And who exactly do you think is to blame for the virus problem? Ah *throwshishandsintheair*.

Ciao, Dscho

Johannes Schindelin a écrit :

I may be different, but I can swear that I live without anti-virus and I have still to see a virus on my computers. I just refrain from downloading all these nice-very-little-useless gizmo for Windows.

Pascal.

Yup. That looks like it - dontcha just gotta love the way some vendors abuse the Windows OS.

I think I'll give msysgit a try, failing that I can always disable the Embassy Suite (since it seems it's only needed for the fingerprint reader which I don't use anyways).

Guys, thanks for all your help - you've been terrific.

Paul

On Jan 17, 2008 1:24 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Paul Umbers, Thu, Jan 17, 2008 19:37:37 +0100:

no need for "make install", just "make" would be enough: you run the commands explicitely in the current directory:

    strace -o log -mall -f ./git --exec-path $(pwd) add testfile

Are you sure? It looks like a strace of some random git program... The link, which failed in log_2 attempt is not even called. Oh... Could you redo the test after running "git reset --hard" first?

And have you tried running tests in a directory without whitespace in path? Like "c:/windows", for example?

Alex Riesen wrote:

That is a matter of opinion. Besides, Cygwin's strace was designed first and foremost with debugging the Cygwin dll in mind. Perhaps the choice of name for the utility was a poor one, since it implies that it ought to be the same as the official strace.

As for the matter at hand:

First, *you must* make sure you inspect every directory in your PATH for other copies of cygwin1.dll. Sometimes, without telling you, other software packages will distribute the cygwin1.dll. Often times this is an older version of that dll. If there are any these found outside of the Cygwin installation tree, you must remove them from your PATH.

Secondly, reinstalling Cygwin by rerunning setup is not enough. Cygwin is pretty self-contained and non-invasive (contrary to the popular FUD spread by MinGWists), but it does have 2 Registry keys which should be axed if you want a clean install. They are:

HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_LOCAL_MACHINE\Software\Cygnus Solutions

Lastly, has the user actually tried reporting this problem to "cygwin@cygwin.com"? That is the proper list for reporting problems with official cygwin packaged applications. Both the maintainer of the "git" Cygwin package and the core Cygwin developers monitor that list, so you are much more likely to get a solution to your problem there. Nevertheless, it does seem that in this case it might be a problem with git's handling of failures to create hard links. But do keep this in mind for future reference.

Cheers, Nicholas

Nicholas Wourms, Thu, Jan 17, 2008 19:53:44 +0100:

Perhaps. I actually did not intend debugging Cygwin dll at all and just assumed (being used to the very useful output of linux' strace) I get something *useful*. It was kinda usefult, just not exactly for this problem.

As to reporting the issue to cygwin list: there are very trivial problems which when long enough overlooked tend to give an impression of malignant stupidity. I expect a wish to change the output of this particular program in this particular project wont ever be granted however long argued and whatever the arguments.

Prove me wrong (IOW: report it to cygwin and see something good happen).

Sorry, screwed up the log.tar.gz ... try this one.

On Jan 16, 2008 11:31 AM, Alex Riesen <raa.lkml@gmail.com> wrote:

Paul Umbers a écrit :

Avoid text-mode on Windows with Cygwin. I can't help with your problem but I can tell you that Git is working fine here!

What about permissions for /cygdrive/c/test ?

Pascal.