Greetings, David Allsopp! > Andrey Repin wrote: >> Greetings, David Allsopp! >> >> > Is this expected behaviour: >> >> > OPAM+DRA@OPAM ~ >> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar >> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM >> > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin >> > 0022 >> > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo >> > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo >> >> > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not >> > sure what to look at on my system to diagnose what I may have >> > inadvertently tweaked. The directory itself is: >> >> > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar >> >> Let me guess, /tmp usertemp ?
> No - it's default mounts, so /tmp = C:\cygwin\tmp, to which my > (non-administrative) user has write access. >> You have extended ACL on the object. And overall, umask is not a good >> idea in Windows. > "umask is not a good idea in Windows" - where's that come from? From knowledge and experience. umask is strictly simple POSIX modes concept. In the ACL environment it is anything from inappropriate to disastrous, but never useful. > (In the actual scenario where I'm being bitten by this, it's because a git > checkout is altering files which were 644 to be 664, so whether it's > precisely umask or not, the *change* of permissions is the problem). Use setfacl. -- With best regards, Andrey Repin Wednesday, March 21, 2018 15:32:21 Sorry for my terrible english...
