Re: Execute bit getting set on created files when it shouldn't

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Wed, 21 Dec 2005, Don Peterson wrote:

> Please reference the mail list thread
> http://sourceware.org/ml/cygwin/2005-10/msg00921.html for what I could
> find on this topic.  I didn't find an answer, but I have a suspicion
> that the problem's cause is not due to cygwin's behavior.  Output of
> cygcheck on my machine attached.
>
> Problem statement:  running a non-cygwin program in a console generate
> files with the execute bit set, even if your umask doesn't allow it.

That's because non-Cygwin programs don't know about Cygwin umask.  FYI,
you can get Cygwin programs to behave the same way by setting
CYGWIN=nontsec.

> The only annoyance of this is that subsequent use of 'ls --color=auto'
> results in lots of files showing up as executables that really aren't.
>
> For one occurrence of this behavior, it's ignorable.  However, it's the
> apocryphal Chinese water torture after thousands of occurrences.  I've
> happily used cygwin on NT4 and Win2000 from 1997 or so to around the
> middle of 2005 and this problem never occurred (not to mention lots of
> time on UNIX machines that also don't exhibit this behavior).  I bought
> a new computer last summer with XP, installed cygwin, restored my
> .profile/.bashrc stuff, and started seeing the problem.  I suspect the
> root cause is that XP changed its permissions behavior from how
> Win2000/NT4 behaved.

Actually, it has nothing to do with the OS -- I've had the same problem on
Win2k, before we went to XP.  It has to do with inheritable directory
permissions -- you must've had the parent directory's "file execute" ACL
turned off on Win2k, and XP turned it on by default.

You could try playing with permission inheritance to fix this...

> I use the following shell function as a quick hack to recursively fix
> things:
>
> unx () {
>     find . -type d | xargs chmod a+x;
>     find . -type f ! -name "*.exe" | xargs chmod a-x
> }

...or you could use a more comprehensive script I posted in
<http://cygwin.com/ml/cygwin/2005-10/msg00935.html>. :-)

> Its problem is that it doesn't work on file names with space characters
> (one could hack on find to add a -Q option to quote any filenames with

Actually, using "find -print0 | xargs -r0" is the preferred way.

> spaces etc. so that hopefully xargs would do the right thing).  An
> undesirable side effect is that e.g. files that are scripts where you do
> want them to be executable are changed to nonexecutable.
>
> One tip:  if you're using InfoZip's unzip command, be sure to add the -X
> option to restore access control lists.  This cuts down on the problem.
> I use the alias 'alias unzip="unzip -X"'.

Or use the Cygwin unzip package... :-)

> Here's an example of the problem on my machine (I took out some
> unrelated cruft):
>
> --> ls -l
> total 80
> -rw-r--r--  1 Don None 19482 Jul 23  2002 md5.c
> --> gcc -c md5.c
> --> ls -l
> total 85
> -rw-r--r--  1 Don None 19482 Jul 23  2002 md5.c
> -rwxr-xr-x  1 Don None  4617 Dec 21 12:19 md5.o
>
> The md5.o file has its execute bits set.  This occurs even if I have my
> umask set to 0122.

Umm, are you using a non-Cygwin gcc?  Why?

> However, if I execute 'rm md5.o; touch md5.o' (i.e., use a cygwin tool),
> the permissions are as I expect (i.e., no execute bits set, even if my
> umask is 0).  This tells me the problem is not caused by cygwin, but
> rather by Windows.
>
> My question for the esteemed cygwin folks is:  Does anyone have an idea
> for a workaround that could eliminate or mitigate this behavior?
>
> If there's no workaround, one day I'll get around to writing a fix for
> the above unx function which turns the execute bits off for all files
> except for those where the first two characters are '#!'.  I think this
> should work, since *.exe files don't need the permission bit set in
> order to run either from bash or Windows Explorer.  *.com files, though,
> do need the bit, as do *.bat files.  For me, this is ignorable, since I
> essentially don't use them.

Actually, DLLs also need to be executable.  The script at the link above
should take care of it.

> PS:  I'd like to thank the cygwin developers and the Red Hat executives
> (past and present) who continue to support cygwin.  Life on Windows
> would be miserable without your work and dedication.

Hear, hear...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/