Re: test -r or -x always return false on an NFS mount?
Greetings, Mario Emmenlauer! > thanks for the awesome Cygwin, its really great! > But since today I met a problem: I mounted a Linux NFSv3 share using > the Windows 10 shipped NFS client. The user and group ID are mapped > via registry settings AnonymousUid and AnonymousGid in the entry > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default > 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. > I've read https://cygwin.com/cygwin-ug-net/using-filemodes.html > about the Cygwin file permissions for NFS, and also the NFS account > mapping at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs, > but as far as I can see, they are both unrelated. Google turned up no > useful hits for keywords "cygwin" "test" and "nfs", so I'm a bit at the > end of my wit. > Is this a known issue, and/or are there any workarounds? I'm currently > using `test -e` in place of read or execute checks, but it basically > breaks all my build scrips. 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. -- With best regards, Andrey Repin Tuesday, October 6, 2020 18:42:12 Sorry for my terrible english... -- 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
Re: test -r or -x always return false on an NFS mount?
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`? Cheers, Mario Emmenlauer -- 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
USA-Based answering service for Village Mart?
Hi there, Curious to know if your company could use help answering incoming calls during and/or after hours. Our company specializes in Inbound Answering services: We can handle both simple/advanced functions as needed. Think of us like an extension of your practice that reduces stress/call burden. *Would you like an Inbound Call Answering Services quote? *All I need is for you to reply, let me know your expected (monthly) call volume & a good number myself or one of my associates can reach you. If there's anything further you need, please let me know! Thanks, Gary Lucero FDN Call Outsourcing If you no longer would like to receive emails, please respond "STOP" [image: beacon] -- 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
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
Thanks for your replies.
This issue only happens when a program is run from cmd.exe, not from a
Cygwin bash shell.
This is important for me, since I discovered this bug in a project
that must be run from Windows graphical shell (i.e. there is no
sensible way to run it through Cygwin and Bash).
> Please show us the output from "uname -a" and "locale" run from the bash
> prompt.
> Please provide the results of "locale" command right before running your test
> binary.
Here are the more detailed steps to reproduce the issue (along with
answers to your requests about `uname`, `locale`, etc.).
(I mostly reproduced what billziss-gh had done before, I do not take
all the credits :D)
Here is an example C file
$ cat example.c
#include
const char *GetCommandLineA(void);
int main(int argc, char *argv[])
{
const char *s = GetCommandLineA();
printf("C=%s\n", s);
for (int i = 0; argc > i; i++)
printf("%d=%s\n", i, argv[i]);
return 0;
}
I have built it with gcc from Cygwin
$ gcc -o binary example.c
Running it from the same Cygwin bash prompt works as expected
$ uname -a
CYGWIN_NT-10.0 XPS 3.1.5(0.340/5/3) 2020-06-01 08:59 x86_64 Cygwin
# (XPS is my Windows machine name)
$ locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_ALL=
$ which gcc
/usr/bin/gcc
# The following runs as expected
$ ./binary.exe "foo bar" "Jérôme"
C="C:\Users\Public\binary.exe"
0=./binary
1=foo bar
2=Jérôme
Now, let's start a Windows shell (cmd.exe)
Note that I had to copy cygwin1.dll from my Cygwin installation
directory, otherwise binary.exe would not start.
I do not know whether there is a `locale` equivalent in Windows
command prompt, so I merely ran my program.
C:\Users\Public>binary.exe "foo bar" "Jérôme"
C=binary.exe "foo bar" "J□r□me"
0=binary
1=foo bar
2="Jérôme"
This behaviour is not expected and is quite inconsistent with what
happened through Bash.
Besides the "strange squares" that appear on the first line, and the
extra space after binary.exe, I especially did not expect "Jérôme" to
remain quoted as a second argument.
Sorry for the delay in my answer. I hope this is now clear, please ask
me for more examples or investigation if you need.
Thanks for your help.
Jérôme
--
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
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
Greetings, Jérôme Froissart! > Now, let's start a Windows shell (cmd.exe) That explains it. > Note that I had to copy cygwin1.dll from my Cygwin installation > directory, otherwise binary.exe would not start. > I do not know whether there is a `locale` equivalent in Windows We've specifically asked to run Cygwin's /bin/locale.exe tool. > command prompt, so I merely ran my program. > C:\Users\Public>binary.exe "foo bar" "Jérôme" > C=binary.exe "foo bar" "J□r□me" > 0=binary > 1=foo bar > 2="Jérôme" > This behaviour is not expected and is quite inconsistent with what > happened through Bash. > Besides the "strange squares" that appear on the first line, and the 1. Run CMD in a more capable terminal. Either M$ Terminal 1.0, or select true type font for your console. > extra space after binary.exe, I especially did not expect "Jérôme" to > remain quoted as a second argument. 2. Then you are parsing the command line wrong. In Windows, it is up to called program to parse the command line. > Sorry for the delay in my answer. I hope this is now clear, please ask > me for more examples or investigation if you need. > Thanks for your help. -- With best regards, Andrey Repin Wednesday, October 7, 2020 1:02:59 Sorry for my terrible english... -- 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
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-06 15:36, Jérôme Froissart wrote: > Thanks for your replies. > This issue only happens when a program is run from cmd.exe, not from a > Cygwin bash shell. > This is important for me, since I discovered this bug in a project > that must be run from Windows graphical shell (i.e. there is no > sensible way to run it through Cygwin and Bash). > >> Please show us the output from "uname -a" and "locale" run from the bash >> prompt. > >> Please provide the results of "locale" command right before running your test >> binary. > Here are the more detailed steps to reproduce the issue (along with > answers to your requests about `uname`, `locale`, etc.). > (I mostly reproduced what billziss-gh had done before, I do not take > all the credits :D) > > Here is an example C file > I have built it with gcc from Cygwin > $ gcc -o binary example.c > > Running it from the same Cygwin bash prompt works as expected > $ uname -a > CYGWIN_NT-10.0 XPS 3.1.5(0.340/5/3) 2020-06-01 08:59 x86_64 Cygwin > # (XPS is my Windows machine name) > > $ locale > LANG=fr_FR.UTF-8 > LC_CTYPE="fr_FR.UTF-8" > LC_NUMERIC="fr_FR.UTF-8" > LC_TIME="fr_FR.UTF-8" > LC_COLLATE="fr_FR.UTF-8" > LC_MONETARY="fr_FR.UTF-8" > LC_MESSAGES="fr_FR.UTF-8" > LC_ALL= > > $ which gcc > /usr/bin/gcc > > # The following runs as expected > $ ./binary.exe "foo bar" "Jérôme" > C="C:\Users\Public\binary.exe" > 0=./binary > 1=foo bar > 2=Jérôme > > Now, let's start a Windows shell (cmd.exe) > Note that I had to copy cygwin1.dll from my Cygwin installation > directory, otherwise binary.exe would not start. > I do not know whether there is a `locale` equivalent in Windows > command prompt, so I merely ran my program. > C:\Users\Public>binary.exe "foo bar" "Jérôme" > C=binary.exe "foo bar" "J□r□me" > 0=binary > 1=foo bar > 2="Jérôme" > > This behaviour is not expected and is quite inconsistent with what > happened through Bash. > Besides the "strange squares" that appear on the first line, and the > extra space after binary.exe, I especially did not expect "Jérôme" to > remain quoted as a second argument. > > Sorry for the delay in my answer. I hope this is now clear, please ask > me for more examples or investigation if you need. > Thanks for your help. Create a new or change your current Command Prompt shortcut to run: "%windir%\system32\cmd /u" "/U Causes the output of internal commands to a pipe or file to be Unicode" and add "chcp 65001": "%windir%\system32\cmd /u /k chcp 65001" or set HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\Autorun or HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun to command "@chcp 65001 > nul" e.g. > reg add HKEY_CURRENT_USER\Software\Microsoft\Command Processor ^ /v AutoRun /d "@chcp 65001 > nul" /f -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- 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
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
Am 06.10.2020 um 23:36 schrieb Jérôme Froissart: Thanks for your replies. This issue only happens when a program is run from cmd.exe, not from a Cygwin bash shell. This is important for me, since I discovered this bug in a project that must be run from Windows graphical shell (i.e. there is no sensible way to run it through Cygwin and Bash). Please show us the output from "uname -a" and "locale" run from the bash prompt. Running it from the same Cygwin bash prompt works as expected $ uname -a CYGWIN_NT-10.0 XPS 3.1.5(0.340/5/3) 2020-06-01 08:59 x86_64 Cygwin Please update to cygwin 3.1.7; there were issues about command line quoting before, I'm not sure whether there was a tweak since 3.1.5 already. -- 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
