The problem is very likely one of the minimal implementation in MSYS tools. You would also be restricted from making changes you cannot change with a Windows tool like attrib.exe.
$ >test
$ ls -l test
-rw-r--r-- 1 kbulgrie Administ 0 Aug 24 13:51 test
$ chmod u-w test
$ ls -l test
-r--r--r-- 1 kbulgrie Administ 0 Aug 24 13:51 test
$ chmod u+w test
$ ls -l test
-rw-r--r-- 1 kbulgrie Administ 0 Aug 24 13:51 test
As you can see, chmod works fine. Now, see what happens with attrib.exe, a Windows binary:
$ ls -l test
-rw-r--r-- 1 kbulgrie Administ 0 Aug 24 13:51 test
$ attrib +R test
$ ls -l test
-r--r--r-- 1 kbulgrie Administ 0 Aug 24 13:51 test
$ attrib -R test
$ ls -l test
-rw-r--r-- 1 kbulgrie Administ 0 Aug 24 13:51 test
attrib, the Windows tool, is agnostic about the ugoa permissions and simplifies things down to having or not having rights:
$ attrib +R test
$ attrib test
R C:\msys\1.0\home\kbulgrien\test
I'm note sure its fair to expect an MSYS tool to do more than the Windows "equivalent". The M in MSYS means "Minimal".
cacls.exe can do some things under MSYS. For instance, this says I and Administrators have full control even though ls -l
appears to say Administrat doesn't have write. Be careful. If on Windows, perhaps use Windows methods.
$ cacls test
C:\msys\1.0\home\kbulgrien\test BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
APD\kbulgrien:F
BUILTIN\Users:R
The following command is one I use in an MSYS environment to fix permissions on SQL database files after I restore from archive. You can run Windows binaries from MSYS. I do it all the time... for instance, scripts run diskpart, format, etc. in an MSYS shell without invoking cmd.exe.
$ cacls "Mantis*.*" //E //G "NETWORK SERVICE":F