Fair enough.  You can move it to another directory in order to delete
the containing directory -- this is what Cygwin does to placate posix


That is because the MSYS runtime is based on an old version of Cygwin,
and it uses the same dirty tricks to emulate fork.  These tricks rely on
having a repeatably consistent memory layout for a process each time it
is started, and when third party tools add hooks that affect the load
order or otherwise screw with the layout, the fork emulation fails. 
This is also why it is sometimes necessary to assign unique base
addresses to all libraries (rebaseall) in order to get fork emulation
working again.

So yes, it is unfortunate that some system tools can drastically affect
the ability of Cygwin and MSYS to function, but it's what we live with
to have fork/exec emulation.  I see that there is work afoot to abstract
process creation so that hopefully this won't be as much a concern in
the near future.

Brian
-

[ message continues ]

Hi,


Ah, thanks for the explanation!  (I knew that this thread still had 

We never had the problem in git itself, since we never used fork() on 
Windows.  The problem lies in our usage of bash and perl.

Bash we can fix in the long run (this goes under the keyword 
"builtinification" on the git list), but I do not see our reliance on Perl 
going away, not for git {send-email,cvsimport,cvsexportcommit,svn}.  
These are not too common operations, so common users will be able to do 
without them.

However, if you rely on the CVS/SVN connectors, or send-email, and in any 
case in the short run, you better run Git on Windows only when that funny 
Logitech driver is disabled ;-)

Ciao,
Dscho

-

[ message continues ]

I thought busybox was being used for the core commands? Is ash not 
complete/usable enough (with all the fixes git has had for broken shells) 
to be used? 

I do agree that perl looks unavoidable, but I thought the windows port 
already avoided at least bash. Not true?

(or is it just that even with ash, you end up hitting all the same issues 
with cygwin/msys?)

		Linus
-

[ message continues ]

Hi,


No, not yet.  The problem is not so much ash, as Nguyen, who said that 
gitbox is not there yet.

Ciao,
Dscho

-

[ message continues ]

Hmm... Could the allocation of large contiguous blocks also lock the
system hard? For instance, I avoid starting the test suite on my XP
workstation at work: it locks up hard every time. W2k works.
The system has nothing unusual in it. Well, it has an antivirus
program (which hopefully stopped working after a series of crashes,
which is just as well), an NVidia card with native driver (which is
broken in its own usual ways). Maybe that's enough
-

[ message continues ]

Sounds like a bug to me.
-

[ message continues ]

Hi,


To me, too.  Alas, it works on W2k, so where is the bug?

Ciao,
Dscho

-

[ message continues ]

I'm not smart enough to know without debugging it.  W2K and WXP have
different system libraries and somewhat different memory layouts.  A
bug can get away on one, but not on the other.
-

[ message continues ]