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

[Don Peterson]

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.

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.

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
}

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
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"'.

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.

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.

Don Peterson
donp@gdssw.com

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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygcheck.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20051221/7b82ba20/attachment.ksh>
-------------- next part --------------
--
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/