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

-

Ok, so it is a bit more complicated...
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 ."
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

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
-

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" = 21ae8269cacbe5...
[ message continues ]

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.
-

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

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

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
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

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.
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

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...
[ message continues ]

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

-

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).
-

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:
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

no need for "make install", just "make" would be enough:

you run the commands explicitely in the current directory:
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?

-

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

-

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
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

-

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
-

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
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

-

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.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
-

Hi,
On Thu, 17 Jan 2008, Pascal Obry wrote:
> Linus Torvalds a

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.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
-

Hi,
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

-

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...
-

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
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

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.
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

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
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).
-

Git version is 1.5.3.8.
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

-

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

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

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

Ok, nothing suspicios here.
-

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
--

Computer Science is no more about computers than astronomy is about telescopes.

--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP

paul.umbers@gmail.com

-

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.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
-

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

-