The bash.exe shell using Cygwin commands does work as expected.
...
The bash.exe shell using MSYS2 commands does NOT work as expected.
Cywin is definitely superior to MSYS2 in this respect.
At first, I think that they are **not** two direct competitors. They have
different goals. Cygwin brings a POSIX-compatible environment to Microsoft
Windows. MSYS2 provides an environment **to build native Windows
programs**. That environment is also POSIX-compatible and derived from Cygwin.
Now, on NTFS Cygwin evaluates file permissions using ACLS (Access Control
Lists) from file's security descriptor. This behavior can be turned off by
the `noacl` option on a mount point. And MSYS2 uses `noacp` on default
mount points. Therefore, it doesn't affect ACLs.
If you need to change ACLs of a file stored on NTFS within MSYS2, you may
use native Windows binaries, like `icacls`, for example.
On March 21, 2019 9:38:59 AM "Richard H. McCullough"
<[email protected]> wrote:
Ruslin and David,
The cmd.exe shell using Windows commands does work as expected.
The bash.exe shell using Cygwin commands does work as expected.
The bash shell using WSL/Ubuntu commands does work as expected.
The bash.exe shell using MSYS2 commands does NOT work as expected.
Cywin is definitely superior to MSYS2 in this respect.
I have developed software on GitHub, but none of my current projects are on
GitHub.
I am a "different user" developing different programs in different
environments.
I build Unicon compiler programs as user "unicon".
I build my Knowledge Explorer interpreter programs as user "ke".
I use these programs and build others as user "rhmcc" or "rhm".
Sharing files directly saves a lot of time.
All these programs run on Windows, Linux, and macOS.
Dick
Richard H. McCullough
http://ContextKnowledgeSystems.org
What is your context?
________________________________
From: David Grayson <[email protected]>
Sent: Wednesday, March 20, 2019 5:52 PM
To: [email protected]; [email protected]
Subject: Re: [Msys2-users] msys2 "ls" and "chmod" don't work on Windows 10
I thought MSYS2's POSIX emulation layer, which controls the behavior of
commands like `chmod`, was a fork of Cygwin's. Does Cygwin really give you
more control over permissions than MSYS2? What exactly can you do in
Cygwin that you can't do with MSYS2?
I'm not sure what kinds of files these users and sharing, or how you are
sharing them, but maybe it makes more sense to share them using a version
control system like Git instead of giving multiple users access to the same
actual files.
--David
On Wed, Mar 20, 2019 at 2:09 PM Richard H. McCullough
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/msys2-users
_______________________________________________
Msys2-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/msys2-users
----------
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
