Hi Corinna, great to have you back :-)
On 13.10.20 20:36, Corinna Vinschen wrote:
On Oct 6 18:10, Mario Emmenlauer wrote:
Dear Andrey,
On 06.10.20 17:46, Andrey Repin wrote:
Greetings, Mario Emmenlauer!
thanks for the awesome Cygwin, its really great!
Everything seems to work quite well, and in `ls -la` I can see the
file permissions and user and group entries. But when using `test`
to check for read (`test -r`) or execute permissions (`test -x`), it
always returns false, even for readable files. `ls` on the other hand
shows the permissions correctly, and `cat`ing the files works without
problems.
This is a known issue. For years known.
test only guess -r/-w/-x results based on permissions as it sees them.
But it do not actually try to read/write/execute the subject, which, as you
can imagine, may lead to all sorts of false positives/negatives on filesystems
with less than trivial access control setups.
In other words, don't test for rwx if you can avoid it. The results MAY be
wrong.
Ok, this explains a lot, and I almost guessed as much! But can I ask,
do you happen to know why `ls -l` shows the "correct" permissions
including 'r' and 'x'? It seems `ls` has some magic that `test` is
lacking? And I can not imagine that `ls` would try to open every
file, or does it?.
So could this "magic" be ported from `ls` to `test`?
There's something fishy in your environment. NFS permissions from NFS
shares mounted via Microsoft's NFSv3 are read using some internal
function I got hinted at by the MSFT NFS guys at one point. This
information is then exported as mode bits by Cygwin's stat(2) and used
accordingly by Cygwin's access(2).
Having said that, there's *no* magic at all in the user space
applications other than using Cygwin's stat(2) and access(2) functions.
Consequentially, using Cygwin's ls(1) or test(1) from coreutils, the
results are the expected ones in both cases; just tried it myself, just
to be sure.
So, what's fishy? I don't know, but maybe you're using a non-Cygwin
test(1) accidentally?
I see your point, but to the best of my knowledge there is nothing
fishy. Its a freshly set up computer with an official Windows 10 x64
from Microsoft directly. I've installed all latest updates including
the 2004 update. Cygwin was also just installed a few months ago.
I did use a script to install Cygwin via its installer in an automated
fashion, but I've run the normal, graphical installer a few times since
then to make sure everything is nice and clean.
Calling "which test" shows "/usr/bin/test", but since I use only
bash in all my scripts, I guess it anyways defaults to the builtin.
The only "weak link" in my setup is the NFS mount. I'm no expert
in exporting NFS, nor in mounting NFS from Windows. Maybe something
is fishy there, albeit I did not use any special parameters or
quirks (again, to the best of my knowledge). What I can say is that
I'm limited to NFS v3 since its not a Server-Edition Windows. Also,
I tried my best to open all NFS ports in the firewall but possibly
I'm not running one of the many extended NFS services like lockd
or something. I checked that most are installed, running and use a
static port, but its hard to be sure, since NFS seems to support
quite many "extras".
Is there anything I can do to isolate this further? Its a quite
curious case and I'm basically at the end of my wit...
All the best,
Mario
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
