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/
|\ _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED]
|,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/
