> To paraphrase, the actual Windows attributes which control file access > privileges are not displayed by "ls" and cannot be changed by "chmod".
It works for me. For example, while in MSYS2: ``` $ mkdir /d/foo && cd /d/foo $ touch foo && ls -l foo -rw-r--r-- 1 **** None 0 Mar 21 05:55 foo ``` Now go to CMD: ``` D:\foo>attrib foo A D:\foo\foo D:\foo>attrib +R foo D:\foo>attrib foo A R D:\foo\foo ``` And return to MSYS2: ``` $ ls -l foo -r--r--r-- 1 **** None 0 Mar 21 05:55 foo ``` And it works in the reverse way. MSYS2: ``` $ chmod u+w foo && ls -l foo -rw-r--r-- 1 **** None 0 Mar 21 05:55 foo ``` CMD: ``` D:\foo>attrib foo A D:\foo\foo ``` Or, did you mean ``NTFS security access right'' when you wrote "the actual Windows attributes which control file access privileges"? On 3/21/2019 2:08 AM, Richard H. McCullough wrote: > What you're telling me is very disturbing. > To paraphrase, the actual Windows attributes which control file access > privileges > are not displayed by "ls" and cannot be changed by "chmod". > > That being the case, ordinary software development becomes difficult. > My software development is shared between three Windows users. > I often have to use Cygwin or Windows File Explorer to fix access problems. > I will probably abandon MSYS2, and go back to using Cygwin and WSL/Ubuntu. > > Richard H. McCullough > http://ContextKnowledgeSystems.org > What is your context? > > > On Wed, Mar 20, 2019 at 11:57 AM Ruslan Garipov <ruslanngari...@gmail.com> > wrote: > >> It looks like `ls(1)` for Win32 calls the `GetFileInformationByHandle` >> function[1] when it checks file modes. Therefore, it operates by file >> attributes (`FILE_ATTRIBUTE_READONLY`, `FILE_ATTRIBUTE_DIRECTORY`, >> etc.), which don't affect users in the file's group (g) or other users >> not in the file's group (o). The similar stuff is applied to >> `chmod(1)`. >> >> The security descriptors in Microsoft Windows have ``primary group'' >> information, which, I believe, exists there for compatibility with >> POSIX, but GNU's coreutils don't use it. May be because that ``primary >> group'' exists only on NTFS. >> >>> $ ls -l csv.icn >>> -rw-r--r-- >> >> On Win32 ``rw-'' stands for ``file without read-only attribute''. It >> looks like `r--` for ``g'' and ``o'' is a default for `ls(1)` on Win32 >> (but I'm not sure, because I didn't find that in source code). >> >>> $ chmod 775 csv.icn >> >> The only thing you can make with `chmod(1)` on Win32 is set ``Readonly'' >> attribute with `chmod u-w csv.icn`. Operations with ``g'' and ``o'' are >> effectively ignored. >> >> May be I'm wrong somewhere; in this case I hope someone will correct me. >> >> [1] >> >> https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-getfileinformationbyhandle >> >> On 3/20/2019 7:26 PM, Richard H. McCullough wrote: >>> "ls" typically lists the same incorrect permissions for all files. >>> "chmod" does not change permissions. >>> >>> Are these commands going to be updated? >>> >>> examples: >>> >>> rhmcc@rhmZ570 MSYS /c/msys64/home/ke/KE/parser >>> $ ls -l csv.icn >>> -rw-r--r-- 1 rhmcc rhmcc 2079 Dec 30 14:55 csv.icn >>> >>> rhmcc@rhmZ570 MSYS /c/msys64/home/ke/KE/parser >>> $ chmod 775 csv.icn >>> >>> rhmcc@rhmZ570 MSYS /c/msys64/home/ke/KE/parser >>> $ ls -l csv.icn >>> -rw-r--r-- 1 rhmcc rhmcc 2079 Dec 30 14:55 csv.icn >>> >>> rhmcc@rhmZ570 MSYS /c/msys64/home/ke/KE/parser >>> >>> Richard H. McCullough >>> http://ContextKnowledgeSystems.org >>> What is your context? >>> >>> >>> >>> _______________________________________________ >>> Msys2-users mailing list >>> Msys2-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/msys2-users >>> >> > -- Yours truly, Ruslan Garipov <ruslanngaripov at gmail dot com>. ---------------------------------------------- MinGW-w64 developer, with write after approval GEDKeeper collaborator _______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
