DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=WZLE+ibhIBhU6FrzW8rQeO7VinYx32HLk6jV56F+F6WI6jghc4YOD
	jefXw8Vec/bdyK5cVx7PkudyaSoqL1SeWmDr/3Rg/RbXBdC7dowLLgig9f8sPP9h
	uHiYq4VlatW7nB/wz6Iz/0ESt+P0PiaCmQO0QstT1pd4yJQYvF/Fx0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: Rick Springob <rspringob AT gmail DOT com>
Subject: Re: python binary retrieved via (cygwin) git clone does not execute - error 127 - SOLVED
Date: Thu, 25 Jun 2015 12:30:33 +0000 (UTC)
Lines: 1
Message-ID: <loom.20150625T124519-957@post.gmane.org>
References: <loom DOT 20150624T153415-310 AT post DOT gmane DOT org> <FABB9FE6-2341-42F1-8EAB-2C0E3E657AA4 AT duaneellis DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
User-Agent: Loom/3.14 (http://gmane.org/)
Content-Transfer-Encoding: 8bit

Duane Ellis <duane <at> duaneellis.com> writes:

> 
> > The problem has only been seen with the git 
> > that ships with 64-bit cygwin.
> 
> Use “ldd” - against the executable, determine the exact file (absolute
path) of every dll that is used/required.
> 
> Including any missing DLLs.
> 
> You might also need to walk through your “Python Library” (where all of
the python loadable modules are stored)
> Remember: LDD will only tell you the DLLs that are used, it will not tell
you about the modules that are loaded.
> 
> Use a “DLL Explorer” program to determine exactly what type of DLL  (32bit
or 64bit) of each DLL.
> Examples: Dependancy Walker, ‘DumpBin” - there are a number of tools that help
> 
> Painful process   I have ran into this many times with other things.
> 
> have also run into problems with Python DLLs built with different versions
of Visual Studio.
> (The C runtime library is different)
> 
> In the end, I have had to put a shell wrapper around Python - so that it
would *change/reset” various Python
> ENV variables.
> 
> With multiple versions of python (32,64, 2.7, 3.0, windows, cygwin,
local-build) nothing is consistent.
> 
> Again painful.
> 
> 

Thanks, Duane.

You are definitely correct that locating all the loaded modules would take
awhile. The python binary only statically loads 4 Windows DLL's.

Though, this didn't seem to be the rabbit hole I should go down. The MD5 sum
is the same for the python.exe binaries whether they executed or not. 

I did an experiment. I copied the binary to another directory and executed
there. It worked! So, it was something about where the binary was rather
than what it was.

It turned out that the directory permissions were not correct:

# On the repo that works.
$ icacls windows
windows USWIN\V605040:(I)(F)
        CREATOR OWNER:(I)(OI)(CI)(IO)(F)
        USWIN\Domain Users:(I)(RX)
        CREATOR GROUP:(I)(OI)(CI)(IO)(RX)
        Everyone:(I)(OI)(CI)(RX)

# On the repo that does not work.
$ icacls windows
windows USWIN\V605040:(F)
        USWIN\Domain Users:(RX)
        Everyone:(RX)
        CREATOR OWNER:(OI)(CI)(IO)(F)
        CREATOR GROUP:(OI)(CI)(IO)(RX)
        Everyone:(OI)(CI)(IO)(RX)

The directory did not inherit permissions from its parent. Using explorer I
went to the advanced security settings and checked the "Replace all child
object permissions with the inheritable permissions from this object."

Voila! The failing binary started working.

Not sure that this is a cygwin/git bug. I would think this behavior would be
more widely reported if it was a bug. 

It is more likely that the problem was caused by either a security policy or
the "IT approved" version of cygwin had been modified. Company issued
laptops are heavily managed by IT department where I work. (And, dog slow
because of all the installed nannies.)