Greetings, Rick Springob! > 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 a Cygwin, but it is not a bug, rather - intended behavior. You can get around it by setting "noacl" flag on mount points you want to be managed by Windows, or explicitly chmod +x necessary binaries. (Though, they SHOULD be chmod'd in the git. Else it is just not suitable for the job of VCS.) > 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.) .........no comments. -- With best regards, Andrey Repin Thursday, June 25, 2015 15:33:56 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
