On Mar 30 19:55, mihau wrote: > >Btw., if you wget a file it's *supposed* to be non-executable. Assuming > >your umask is 0022, the file will be create with 0644 permissions. The > >default ACL created in this case explicitely disables execution for the > >admin user if the admin user is part of the ACL. Just run `chmod +x' > >afterwards if that's the only problem. > > I specifically meant exe as in windows executables, files w/ .exe suffix; > just tried "chmod +x" and you are correct, it works, my helloworld.exe > became executable indeed. thank you for that. > > any idea why wget cygwin interferes with those things though? > in my understanding it should just copy/save a file from a remote server > to a local computer, without even touching file permissions or such. That's not how it works. Consider that the file wget downloads doesn't exist yet on your side. When creating the file on your local machine, wget has to call open(2) with a set of permisssions. The set of permissions given by wget does *not* contain an execute bit. The old permission implementation in Cygwin ignored this fact for ACEs inherited from the parent directory. This, however, leads to incorrect POSIX permission bits if implemanted correctly. The recent versions of Cygwin starting with version 2.4.0 strive to implement the POSIX permission and ACL handling as correct as possible. And this in turn requires to reflect the correct execute permission setting also in the ACEs inherited from the parent dir. That's why a file downloaded with wget does not have execute permissions at all by default. wget doesn't request them, and for the ACEs inherited from the parent dir Cygwin removes the execute permissions to follow suit. Bottom line, either use rsync if possible, or when using wget try if the --preserve-permissions option fixes your problem. Alternatively, fall back to chmod +x. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat