"make test" works again (sort-of) on cygwin.

Hi *,

Having upgraded to version 1.5.6 (via tarball), I can "make test" once
again, without crashing my machine. (well, it grinds to a halt, so that
I have to pull the power cord, followed by the battery!) I have been
unable to do that since v1.5.3!

I spent many hours (not recently) trying to determine the reason for
the crash, but it seems to be essentially "random gremlins" :-)
However, since I mostly use Linux, I've not been very motivated to
find a solution, particularly when git works fine (touch wood) when
used for real work. (i.e. only "make test" crashes my machine).
Also, as Alex and Shawn have not reported problems, I have assumed
it is something specific to my environment. Dunno.

Anyhow, the "sort-of" in the subject line, relates to the fact that
I am seeing some test failures.  In particular, all tests in
t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
tests involve chmod/permissions ...

I haven't spent too long trying to debug this, but looking at the
first (actually second) test in t0004, I did an strace on git-write-tree.
After wading through the output, it seems that cygwin allows mkdir()
to succeed in the (un-writable) .git/object directory; eg. when
writing the tree object 47d832... it succeeds in making the 47 directory
(which does have write permission) followed by the d832... file.
So I tried this by hand:

    $ mkdir obj
    $ chmod a-w obj
    $ echo file >obj/file
    bash: obj/file: Permission denied
    $ mkdir obj/dir
    $

OK.

[Junio, in the tarball, the test files t5304-prune.sh and
t7610-mergetool.sh do not have the executable bit set]

ATB,

Ramsay Jones

Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:

I spent many hours (not recently) trying to determine the reason for
the crash, but it seems to be essentially "random gremlins" :-)
However, since I mostly use Linux, I've not been very motivated to
find a solution, particularly when git works fine (touch wood) when
used for real work. (i.e. only "make test" crashes my machine).
Also, as Alex and Shawn have not reported problems, I have assumed
it is something specific to my environment. Dunno.

I haven't tried to run the test on XP recently (it is a production
workstation, after all), but the last time I risked it was locked up
hard. Win2k runs (and I even can work, well, browse, on it)

Anyhow, the "sort-of" in the subject line, relates to the fact that
I am seeing some test failures.  In particular, all tests in
t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
tests involve chmod/permissions ...

Don't run "make test" as root (or "backup operator" on windows).
OTOH, a windows machine is almost useless, unless you're a member of
local administrators group (which includes "backup" permission).

Hi,

On Thu, 3 Jul 2008, Ramsay Jones wrote:

Hi *,

Having upgraded to version 1.5.6 (via tarball), I can "make test" once
again, without crashing my machine.

Earlier, I would have been more than ready to suggest using msysGit.  But 
as I became more than just frustrated with "users" (after all, Git users 
are supposed to be developers), I refrain more and more from doing so.

Having said that, you _might_ get lucky trying msysGit, even from Cygwin.  
Just do not complain to me when it does not work.

Ciao,
Dscho

P.S.: if it does not work, and you fix a few issues, but have problems 
with others, I might be more inclined to help you, just because you did 
fix some issues.

Alex Riesen wrote:

Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:

quoted

Anyhow, the "sort-of" in the subject line, relates to the fact that
I am seeing some test failures.  In particular, all tests in
t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
tests involve chmod/permissions ...

Don't run "make test" as root (or "backup operator" on windows).
OTOH, a windows machine is almost useless, unless you're a member of
local administrators group (which includes "backup" permission).

Ah, yes... I am a "Computer administator" aren't I ;-) I totally forgot!

Hmm, but is that really the reason for these failures? After all, (referring
to the example you snipped) the permissions are respected for creating
files in the directory, just not directories.  Is the "root" user on
windows only selectively omnipotent?


ATB,

Ramsay Jones

Ramsay Jones, Sat, Jul 05, 2008 22:09:31 +0200:

Alex Riesen wrote:

quoted

Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:

quoted

Anyhow, the "sort-of" in the subject line, relates to the fact that
I am seeing some test failures.  In particular, all tests in
t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
tests involve chmod/permissions ...

Don't run "make test" as root (or "backup operator" on windows).
OTOH, a windows machine is almost useless, unless you're a member of
local administrators group (which includes "backup" permission).

Ah, yes... I am a "Computer administator" aren't I ;-) I totally forgot!

Hmm, but is that really the reason for these failures? After all, (referring
to the example you snipped) the permissions are respected for creating
files in the directory, just not directories.  Is the "root" user on
windows only selectively omnipotent?

It is (it is the backup operators who can read open, even locked,
files), but it is boringly hard to find when and where. You can try
reading MSDN (or better don't, you'll live longer if you don't).

Alex Riesen wrote:

Ramsay Jones, Sat, Jul 05, 2008 22:09:31 +0200:

quoted

Alex Riesen wrote:

quoted

Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:

quoted

Anyhow, the "sort-of" in the subject line, relates to the fact that
I am seeing some test failures.  In particular, all tests in
t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
tests involve chmod/permissions ...

Don't run "make test" as root (or "backup operator" on windows).
OTOH, a windows machine is almost useless, unless you're a member of
local administrators group (which includes "backup" permission).

Ah, yes... I am a "Computer administator" aren't I ;-) I totally forgot!

Hmm, but is that really the reason for these failures? After all, (referring
to the example you snipped) the permissions are respected for creating
files in the directory, just not directories.  Is the "root" user on
windows only selectively omnipotent?

It is (it is the backup operators who can read open, even locked,
files), but it is boringly hard to find when and where. You can try
reading MSDN (or better don't, you'll live longer if you don't).

Yeah, I'm afraid I've had to serve that sentence (several times) in
the past; I'm still trying to figure out what my crime was... ;P

ATB,

Ramsay Jones