From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aldebaran.he1ix.org (aldebaran.he1ix.org [IPv6:2a01:4f8:173:803:0:a1de:ba:a]) by sourceware.org (Postfix) with ESMTP id 26DF03854822 for ; Wed, 14 Oct 2020 09:06:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 26DF03854822 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=emmenlauer.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=mario@emmenlauer.de Received: from ipbcc054c1.dynamic.kabel-deutschland.de ([188.192.84.193] helo=[192.168.1.190]) by aldebaran.he1ix.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1kScjR-000587-7c for cygwin@cygwin.com; Wed, 14 Oct 2020 11:06:01 +0200 To: cygwin@cygwin.com References: <1279009444.20201006184606@yandex.ru> <20201013183650.GW26704@calimero.vinschen.de> <2820bfde-68f4-e2f9-78c4-4174423a6213@emmenlauer.de> <20201014082841.GY26704@calimero.vinschen.de> From: Mario Emmenlauer X-Tagtoolbar-Keys: D20201014110600715 Message-ID: <8afea014-6e68-01ef-f6c8-d947e820ec3a@emmenlauer.de> Date: Wed, 14 Oct 2020 11:06:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201014082841.GY26704@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 188.192.84.193 X-SA-Exim-Mail-From: mario@emmenlauer.de X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, TXREP, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 Subject: Re: test -r or -x always return false on an NFS mount? X-SA-Exim-Version: 4.2.1 (built Sun, 08 Nov 2009 07:31:22 +0000) X-SA-Exim-Scanned: Yes (on aldebaran.he1ix.org) X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 09:06:06 -0000 On 14.10.20 10:28, Corinna Vinschen wrote: > On Oct 13 21:00, Mario Emmenlauer wrote: >> On 13.10.20 20:36, Corinna Vinschen wrote: >>>>>> 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. >>> >>> 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. > > Please check and try again with the stand-alone test(1), too. Sorry, I should have mentioned this: it gives the same result. >> 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... > > Actually, not really. It's weird in fact, given ls(1) shows the > desired result. That would point to a bug in access(2), but there's > no special code in access(2) for NFS. For filesystems not supporting > ACLs (FAT, NFS, etc), it calls stat(2) and checks the st_mode bits > against the requested access(2) mode based on the uid/gid of the > caller, simple as that. Hmm, now that you mention it, I just coincidentally found an issue with the `_stat` call in Microsoft Windows 2004 update. In the Apache thrift project I found that `_stat` stopped working on domain socket files on Windows. This sounds not directly identical, but could be well related. I did not try `_stat` in other situations, but something must have changed there very recently. The issue is reported upstream, but sadly for the wrong product (Visual Studio), so nobody is following up this report anymore: https://developercommunity.visualstudio.com/content/problem/1180994/-stat-fails-on-existing-domain-socket-file-when-bu.html (Scroll to the bottom to see the full report). > Please call ls(1) and test(1) -r (not the bash builtin) on a file > exposing the behaviour under strace like this: > > $ strace -o ls.trace /bin/ls -l > $ strace -o test.trace /bin/test -r > > and send the trace files here, together with the output of the above > ls(1) call and the output of id(1). I will to that! Thanks for your help and interest!! All the best, Mario Emmenlauer