Re: Documenting Cygwin on NFS, no longer only exchange-medium! Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a d
On Sun, 27 Aug 2023 at 14:35, Corinna Vinschen via Cygwin wrote: > > On Aug 26 19:44, Martin Wege via Cygwin wrote: > > On Fri, Aug 25, 2023 at 2:19 PM Corinna Vinschen via Cygwin > > wrote: > > > > > > On Aug 23 01:05, Roland Mainz via Cygwin wrote: > > > > Note that Cygwin does not interpret the file |myfifo.fifo| as FIFO, > > > > instead it comes back as a symlink "myfifo.fifo -> ':\0:c4:1000'". > > > > > > > > AFAIK there are (at least) these two options to fix the problems: > > > > 1. Check whether the filesystem for the fifos path is NFS > > > > (cgywin.dll's |fs.fs_is_nfs()|), and if it is a symlink check if it > > > > starts with ':\0:c4:' (assuming "c4" is the prefix for inodes created > > > > with |mkfifo()|). If this condition is |true|, then cygwin |stat()|, > > > > |open()| etc. should treat this inode as FIFO. > > > > > > The downside is that it is not possible to diffentiate between Cygwin > > > FIFOs and real FIFOs created from the remote side in `ls -l' > > > output. Note that Cygwin returns the NFS stat info verbatim, so > > > a real FIFO is returned as a real FIFO: > > > > > > linux$ mkfifo bar > > > cygwin$ ls -l bar > > > prw-r--r-- 1 corinna vinschen 0 Aug 25 13:58 bar > > > > > > The idea was always to use NFS as exchange medium, but not as > > > installation medium for the entire distro or to keep Cygwin home > > > dirs on NFS. There were times where NFS was pretty unstable. > > > I used NFS for quite some time to build Cygwin packages, but at one > > > point I got trouble (performance problems with multiple concurrent > > > processes accessing an NFS share, build errors out of the blue), > > > so I switched to Samba shares, albeit grudgingly. I'm not yet > > > sure if the problems are fixed. At least a recent OpenSSH build > > > ran through without problems... > > > > Corinna, could you please update the Cygwin documentation then? We use > > NFS, both Windows builtin and CITI NFSv4.1, with Cygwin for years > > without major problems, so that comment about exchange-medium-only is > > clearly wrong! > > I'm talking about the idea how users would use NFS, and the idea was > that nobody in their right mind would use a crippled filesystem (from > the Windows POV) for the entire installation. Before you came up with > your complaints, nobody here even knew that somebody actually did that. What is missing in the Windows NFS filesystem to uncripple (if there is such a word in English) it from a Windows perspective? > > NFS is a niche filesystem on Windows and was never in the focus of > anybody here, except me, because I was toying around with it and was > happy to have it working. As far as I knew until a few days ago, > I was the only user of Cygwin's NFS support. Well, surprise, you were wrong. The Windows NFS filesystem has lots of users, but there are no centralised statistics. Just as an indicator, NFS on Windows has at least enough users to feed a couple of engineers at OpenText to work on their OpenText (once Hummingbird) NFS client product. Plus the two free implementations, Windows builtin NFSv3, and the CITI ms-nfsv41-client. > > As for FIFOs on NFS, as I wrote, they never worked as desired on NFS. > For kicks I tried back until Cygwin 3.3. Given this isn't a regression, > it won't be fixed for Cygwin 3.4. I am pretty sure this is a regression, as blast, staden and other software were built and operated on Cygwin. Just my PAIN job is how to rebuild our compute cluster (after total loss due water damage), new Windows, new blast&friends, new Cygwin. And promptly we got hit by this issue. > > As Brian wrote in his reply to your mail, we are all volunteers here. > Everybody working on Cygwin is working in their spare time and/or on the > goodwill of their employer. > > Cygwin is open source. You can fix or implement stuff yourself and send > the patches to the cygwin-patches ML for review. Otherwise you will > have to let us, the people actually working on the project, decide when > and how something gets implemented. I agree. > > Having said that, I have a local patch enabling FIFOs on NFS. I might > push it at one point to the main branch, but the pressure you guys are > currently building up on this mailing list puts me right off. This was not intended, at least not from my side. But in any case, I humbly apologise. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- 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: process substitution to create a virtual file doesn't work in chroot environment
On Mon, 28 Aug 2023 at 00:14, Cary Lewis via Cygwin wrote: > > In a cygwin process that is started either from mintty or bash directly the > following: > > $ user=234 > > $ ./cat <(echo $user) > 234 > works as expected. > > But after a chroot: > > $ chroot . ./bash > user=234 > $ ./cat <(echo $user) > ./cat: /dev/fd/63: No such file or directory > > In the directory I am chrooting in, I created a tmp folder, as well as > proc, proc/self, and proc/self/fd, and a dev directory. Can you strace -f the bash process to see what happens? How does ls -l /dev/ look like? Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- 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: gawk core dumped on too many input values
On Sun, Aug 27, 2023 at 2:25 PM Ed Morton via Cygwin
wrote:
>
> This (original email below) turned out to be a general cygwin issue, not
> a gawk issue:
>
> $ LC_ALL=C sed 's/x/y/' $(seq 100)
> Segmentation fault (core dumped)
>
> $ LC_ALL=C grep 'foo' $(seq 100)
> Segmentation fault (core dumped)
>
Seems that all commands linked with cygwin1.dll will fault if you pass them
a long enough arglist.
For me, /bin/true faults on {1..258231} but not {1..258230}.
> $ /bin/true {1..258230}
>
> $ /bin/true {1..258231}
> Segmentation fault (core dumped)
strace, which is not linked with cygwin1.dll, exits cleanly.
> $ /bin/strace {1..30}
> -bash: /bin/strace: Argument list too long
See this page [1] on maximum argument lengths.
It would be nice to document this limit, whatever it is.
It would also be nice to return an error to the shell on too-long arglist.
$ cat true.exe.stackdump
>
Exception: STATUS_STACK_OVERFLOW at rip=7FFD41BD4646
> rax=00051F10 rbx=00089991 rcx=0007FFE03C50
> rdx=7FFD41BF58A0 rsi= rdi=
> r8 =FEFEFEFEFEFEFF42 r9 =7FFD41BF5820 r10=FEFEFEFEFEFEFEFF
> r11=FEFEFEFEFEFEFEFF r12=0008998D r13=0007CDF0
> r14= r15=
> rbp=0007CD30 rsp=0007CC38
> program=C:\cygwin64\bin\true.exe, pid 44496, thread
> cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
> Stack trace:
> Frame Function Args
> 0007CD30 7FFD41BD4646 (7FFD41A08035, 7FFD41A06F80, ,
> ) cygwin1.dll+0x1D4646
> 0007CD30 00249F10 (7FFD41A06F80, , ,
> )
> 0007CD30 7FFD41BF5800 (, , ,
> ) cygwin1.dll+0x1F5800
> 0007CD30 7FFD41A08035 (, , ,
> ) cygwin1.dll+0x8035
> 0007FFF0 7FFD41A05C86 (, , ,
> ) cygwin1.dll+0x5C86
> 0007FFF0 7FFD41A05D34 (, , ,
> ) cygwin1.dll+0x5D34
> End of stack trace
> Loaded modules:
> 00010040 true.exe
> 7FFD52F3 ntdll.dll
> 7FFD5225 KERNEL32.DLL
> 7FFD5094 KERNELBASE.dll
> 0005EE2D cygintl-8.dll
> 7FFD41A0 cygwin1.dll
> 0003F9F7 cygiconv-2.dll
> 7FFD51C7 advapi32.dll
> 7FFD51FD msvcrt.dll
> 7FFD525A sechost.dll
> 7FFD5265 RPCRT4.dll
> 7FFD4F3A CRYPTBASE.DLL
> 7FFD5038 bcryptPrimitives.dll
> $ uname -a
> CYGWIN_NT-10.0-22621 nzxt 3.4.8-1.x86_64 2023-08-17 17:02 UTC x86_64 Cygwin
Thanks,
Jeremy Hetzler
[1] https://www.in-ulm.de/~mascheck/various/argmax/
--
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
process substitution to create a virtual file doesn't work in chroot environment
In a cygwin process that is started either from mintty or bash directly the following: $ user=234 $ ./cat <(echo $user) 234 works as expected. But after a chroot: $ chroot . ./bash user=234 $ ./cat <(echo $user) ./cat: /dev/fd/63: No such file or directory In the directory I am chrooting in, I created a tmp folder, as well as proc, proc/self, and proc/self/fd, and a dev directory. Can someone explain why process substitution to create a virtual file doesn't work in a chroot environment? Thank you. -- 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
Fwd: gawk core dumped on too many input values
This (original email below) turned out to be a general cygwin issue, not
a gawk issue:
$ LC_ALL=C sed 's/x/y/' $(seq 100)
Segmentation fault (core dumped)
$ LC_ALL=C grep 'foo' $(seq 100)
Segmentation fault (core dumped)
Regards,
Ed.
Forwarded Message
Subject:gawk core dumped on too many input values
Date: Sun, 27 Aug 2023 08:09:54 -0500
From: Ed Morton
To: bug-g...@gnu.org
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -ggdb -O2 -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
--param=ssp-buffer-size=4
-fdebug-prefix-map=/cygdrive/d/a/scallywag/gawk/gawk-5.2.2-1.x86_64/build=/usr/src/debug/gawk-5.2.2-1
-fdebug-prefix-map=/cygdrive/d/a/scallywag/gawk/gawk-5.2.2-1.x86_64/src/gawk-5.2.2=/usr/src/debug/gawk-5.2.2-1
-DNDEBUG
uname output: CYGWIN_NT-10.0-22621 TournaMart_2023 3.4.8-1.x86_64
2023-08-17 17:02 UTC x86_64 Cygwin
Machine Type: x86_64-pc-cygwin
Gawk Version: 5.2.2
Attestation 1:
I have read
https://www.gnu.org/software/gawk/manual/html_node/Bugs.html.
Yes
Attestation 2:
I have not modified the sources before building gawk.
True
Description:
I was trying to test something related to ARG_MAX when I ran the
awk script below and it core dumped instead of reporting an error
and exiting gracefully. In case it's useful getconf ARG_MAX outputs
32000.
Repeat-By:
$ LC_ALL=C awk 'BEGIN{print ARGC}' $(seq 100)
Segmentation fault (core dumped)
--
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
[ANNOUNCEMENT] screen 4.9.1-1
screen 4.9.1-1 is now available in Cygwin. This release includes bug fixes and documentation updates. See the release announcement[1] and upstream changelog[2] for more details. Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. Each virtual terminal provides the functions of the DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g., insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows the user to move text regions between windows. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the user's terminal. Andrew E. Schulman [1] https://savannah.gnu.org/news/?id=10500 [2] https://git.savannah.gnu.org/cgit/screen.git/log/?h=v.4.9.1 -- 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
[ANNOUNCEMENT] Updated: bzip3 1.3.2
The following packages have been uploaded to the Cygwin distribution: - bzip3 - libbzip3_0 - libbzip3-devel https://cygwin.com/packages/summary/bzip3-src.html -- 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: Documenting Cygwin on NFS, no longer only exchange-medium! Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a d
On Aug 26 19:44, Martin Wege via Cygwin wrote: > On Fri, Aug 25, 2023 at 2:19 PM Corinna Vinschen via Cygwin > wrote: > > > > On Aug 23 01:05, Roland Mainz via Cygwin wrote: > > > Note that Cygwin does not interpret the file |myfifo.fifo| as FIFO, > > > instead it comes back as a symlink "myfifo.fifo -> ':\0:c4:1000'". > > > > > > AFAIK there are (at least) these two options to fix the problems: > > > 1. Check whether the filesystem for the fifos path is NFS > > > (cgywin.dll's |fs.fs_is_nfs()|), and if it is a symlink check if it > > > starts with ':\0:c4:' (assuming "c4" is the prefix for inodes created > > > with |mkfifo()|). If this condition is |true|, then cygwin |stat()|, > > > |open()| etc. should treat this inode as FIFO. > > > > The downside is that it is not possible to diffentiate between Cygwin > > FIFOs and real FIFOs created from the remote side in `ls -l' > > output. Note that Cygwin returns the NFS stat info verbatim, so > > a real FIFO is returned as a real FIFO: > > > > linux$ mkfifo bar > > cygwin$ ls -l bar > > prw-r--r-- 1 corinna vinschen 0 Aug 25 13:58 bar > > > > The idea was always to use NFS as exchange medium, but not as > > installation medium for the entire distro or to keep Cygwin home > > dirs on NFS. There were times where NFS was pretty unstable. > > I used NFS for quite some time to build Cygwin packages, but at one > > point I got trouble (performance problems with multiple concurrent > > processes accessing an NFS share, build errors out of the blue), > > so I switched to Samba shares, albeit grudgingly. I'm not yet > > sure if the problems are fixed. At least a recent OpenSSH build > > ran through without problems... > > Corinna, could you please update the Cygwin documentation then? We use > NFS, both Windows builtin and CITI NFSv4.1, with Cygwin for years > without major problems, so that comment about exchange-medium-only is > clearly wrong! I'm talking about the idea how users would use NFS, and the idea was that nobody in their right mind would use a crippled filesystem (from the Windows POV) for the entire installation. Before you came up with your complaints, nobody here even knew that somebody actually did that. NFS is a niche filesystem on Windows and was never in the focus of anybody here, except me, because I was toying around with it and was happy to have it working. As far as I knew until a few days ago, I was the only user of Cygwin's NFS support. As for FIFOs on NFS, as I wrote, they never worked as desired on NFS. For kicks I tried back until Cygwin 3.3. Given this isn't a regression, it won't be fixed for Cygwin 3.4. As Brian wrote in his reply to your mail, we are all volunteers here. Everybody working on Cygwin is working in their spare time and/or on the goodwill of their employer. Cygwin is open source. You can fix or implement stuff yourself and send the patches to the cygwin-patches ML for review. Otherwise you will have to let us, the people actually working on the project, decide when and how something gets implemented. Having said that, I have a local patch enabling FIFOs on NFS. I might push it at one point to the main branch, but the pressure you guys are currently building up on this mailing list puts me right off. Corinna -- 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
