test -r or -x always return false on an NFS mount?

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Oct 13 18:36:50 GMT 2020

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?


More information about the Cygwin mailing list