Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On 2023-08-26 11:40, Martin Wege via Cygwin wrote: On Sat, Aug 26, 2023 at 4:16 PM Corinna Vinschen via Cygwin wrote: On Aug 26 13:26, Cedric Blancher via Cygwin wrote: On Fri, 25 Aug 2023 at 14:26, Corinna Vinschen via Cygwin wrote: On Aug 25 14:18, Corinna Vinschen via Cygwin wrote: On Aug 23 01:05, Roland Mainz via Cygwin wrote: 2. Check whether the filesystem for the fifos path is NFS (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with |ENOSYS| (not implemented) I like the idea. EPERM, btw. See https://man7.org/linux/man-pages/man2/mknod.2.html I am vehemently opposed to that idea. That will IMHO not only be the wrong solution, it will break actual things like autoconf on NFS - they create fifos for testing, but do not use them. If you just make this return EPERM, then you break stuff we have to rely on. https://cygwin.com/acronyms/#STC, please.# Real world failure for Cygwin on NFS: wget 'http://deb.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.4.orig.tar.gz cd ksh-1.0.4 $PWD/bin/package make This fails with Cygwin 3.4.8-1: cat buildlog.log package: update /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/bin/execrate package: initialize the /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64 view package: update /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/lib/probe/C/make/probe package: update /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/bin/mamake package: make with mamake package: make output captured in /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/lib/package/gen/make.out mkfifo: cannot set permissions of '/cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/lib/package/gen/make.out.fifo': No such file or directory package: make done at Fri Aug 26 19:24:26 CEST 2023 in /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64 If you need more examples just let me now, we have MUCH more of that... No - the DLL developers need fewer examples, just *ONE* Simple Test Case, boiled down to the essentials, with notes on preconditions, if you can not recreate the required conditions in a program or script. Alternatively, Cygwin strace output with notes from a failing program, or a gdb script and log of the failing code with enough calling context and notes. Please read the problem reporting guidelines linked at the bottom of all posts and follow them. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Thu, Aug 24, 2023 at 6:45 PM Martin Wege wrote:
>
> On Wed, Aug 23, 2023 at 1:06 AM Roland Mainz via Cygwin
> wrote:
> >
> > On Tue, Aug 22, 2023 at 4:52 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> > via Cygwin wrote:
> > > > FIFOs which don't make *any* sense
> > > > ... FWIW, a remote NFS fileystem.
> > >
> > > I got an impression that the OP is trying to deploy something (maybe the
> > > entire Cygwin) onto an
> > > NFS share. So the named FIFO "file" is also created in there.
> >
> > I agree with that impression. This is basically what large sites
> > (universities etc) do with UNIX and Linux: The machines mount an
> > user's ${HOMR} directory via automounter over NFS, and users are
> > discouraged (e.g. grumpy admin visiting you in person, blocking all
> > escape routes... =:-) ) from using the machine's local filesystems (in
> > Cygwin's case that includes "C:"!).
> >
> > In that case people want to use |mkfifo()|/|mkfifoat()| and/or
> > /usr/bin/mkfifo in their home directory, and don't expect that it does
> > not work.
> >
> > But that is what happens on Cygwin 3.4.8 right now, if someone tries
> > to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and
> > CITI NFSv4 clients):
> > |mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested
> >
> > Example (/cygdrive/h/ is my home directory shared from my Linux machine):
> > snip
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ uname -a
> > CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC
> > x86_64 Cygwin
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ mount
> > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> > C:/cygwin64 on / type ntfs (binary,auto)
> > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> > H: on /cygdrive/h type nfs (binary,posix=0,user,noumount,auto)
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ls -l
> > total 1
> > -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> > cygwin_mkfifo_on_nfs.c
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ cat -n cygwin_mkfifo_on_nfs.c
> > 1 #include
> > 2 #include
> > 3 #include
> > 4 #include
> > 5 #include
> > 6 #include
> > 7
> > 8 int main(int ac, char *av[])
> > 9 {
> > 10 (void)puts("# start");
> > 11
> > 12 if
> > (mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) != 0)
> > 13 perror("mkfifo failed");
> > 14 (void)puts("# done.");
> > 15 return EXIT_SUCCESS;
> > 16 }
> > 17
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ gcc -g cygwin_mkfifo_on_nfs.c
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ./a
> > # start
> > # done.
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ls -l
> > total 68
> > -rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe
> > -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> > cygwin_mkfifo_on_nfs.c
> > lrwxrwxrwx 1 Unix_User+0 Unix_Group+011 Aug 23 00:12 myfifo.fifo
> > -> ':\0:c4:1000'
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ cat > -bash: myfifo.fifo: No such file or directory
> > snip
> >
> > 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.
> > 2. Check whether the filesystem for the fifos path is NFS
> > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
> > |ENOSYS| (not implemented)
> >
> > Better algorithm for [1] might be to check whether the inode is a
> > symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
> > assuming this is more performant.
>
> We would like to see option 1 implemented, maybe as an option in the
> CYGWIN environment variable
> (CYGWIN=nfs_emulate_dev_special_files_as_symlink ?)
One problem I see is how we can set machine-wide defaults, as the
CYGWIN variable is only inherited from process to process, and
/usr/bin/env - myprog will start myprog with an empty environment.
So if there is no way to set machine-wide defaults, I would prefer to
have the nfs_emulate_dev_special_files_as_symlink enabled by default.
Thanks,
Martin
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Sat, Aug 26, 2023 at 4:16 PM Corinna Vinschen via Cygwin wrote: > > On Aug 26 13:26, Cedric Blancher via Cygwin wrote: > > On Fri, 25 Aug 2023 at 14:26, Corinna Vinschen via Cygwin > > wrote: > > > > > > On Aug 25 14:18, Corinna Vinschen via Cygwin wrote: > > > > On Aug 23 01:05, Roland Mainz via Cygwin wrote: > > > > > 2. Check whether the filesystem for the fifos path is NFS > > > > > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > > > > > |ENOSYS| (not implemented) > > > > > > > > I like the idea. > > > > > > EPERM, btw. See https://man7.org/linux/man-pages/man2/mknod.2.html > > > > > > > I am vehemently opposed to that idea. That will IMHO not only be the > > wrong solution, it will break actual things like autoconf on > > NFS - they create fifos for testing, but do not use them. If you just > > make this return EPERM, then you break stuff we have to rely on. > > https://cygwin.com/acronyms/#STC, please.# Real world failure for Cygwin on NFS: wget 'http://deb.debian.org/debian/pool/main/k/ksh93u+m/ksh93u+m_1.0.4.orig.tar.gz cd ksh-1.0.4 $PWD/bin/package make This fails with Cygwin 3.4.8-1: cat buildlog.log package: update /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/bin/execrate package: initialize the /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64 view package: update /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/lib/probe/C/make/probe package: update /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/bin/mamake package: make with mamake package: make output captured in /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/lib/package/gen/make.out mkfifo: cannot set permissions of '/cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64/lib/package/gen/make.out.fifo': No such file or directory package: make done at Fri Aug 26 19:24:26 CEST 2023 in /cygdrive/z/arbeitdfn/windows_ksh/build_nfsv3/ksh-1.0.4/arch/cygwin.i386-64 If you need more examples just let me now, we have MUCH more of that... Thanks, Martin -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
> You don't seem to understand the problem. I think I do, and that aligns with your explanation how Cygwin machinery works to fake the FIFOs. > If I can recognize a file as FIFO, I can use it as FIFO, regardless if it's a > native FIFO or a Cygwin FIFO. That's exactly what I meant! > Show me how to create a FIFO on NTFS or FAT by OS calls only, please. > Again, there is no API to create native FIFOs on a remote NFS filesystem. And because of the above, Cygwin can keep creating FIFOs as before, on any filesystem. Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Aug 25 23:21, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > it is not possible to diffentiate between Cygwin > > FIFOs and real FIFOs created from the remote side in `ls -l' > > output. > > Why would that be necessary? If it's a FIFO, it can be used as a > FIFO, regardless where and how it was created.. You don't seem to understand the problem. A Cygwin FIFO is not a real FIFO. We're running on Windows, right? Show me how to create a FIFO on NTFS or FAT by OS calls only, please. Cygwin's way of creating FIFOs is to create a Cygwin syumlink with special content which in turn is faked to be a FIFO when running Cygwin's stat(2) call. Usually that's a Windows shortcut (one of the .lnk thingies), but on NFS we create a real symlink with weird content *accidentally*, because that's how we create symlinks on NFS, and nobody ever cared to that anyway. Again, there is no API to create native FIFOs on a remote NFS filesystem. But, ultimately, you're still right. If I can recognize a file as FIFO, I can use it as FIFO, regardless if it's a native FIFO or a Cygwin FIFO. This just isn't done yet. 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
Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Aug 26 13:26, Cedric Blancher via Cygwin wrote: > On Fri, 25 Aug 2023 at 14:26, Corinna Vinschen via Cygwin > wrote: > > > > On Aug 25 14:18, Corinna Vinschen via Cygwin wrote: > > > On Aug 23 01:05, Roland Mainz via Cygwin wrote: > > > > 2. Check whether the filesystem for the fifos path is NFS > > > > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > > > > |ENOSYS| (not implemented) > > > > > > I like the idea. > > > > EPERM, btw. See https://man7.org/linux/man-pages/man2/mknod.2.html > > > > I am vehemently opposed to that idea. That will IMHO not only be the > wrong solution, it will break actual things like autoconf on > NFS - they create fifos for testing, but do not use them. If you just > make this return EPERM, then you break stuff we have to rely on. https://cygwin.com/acronyms/#STC, please. 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
Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Fri, 25 Aug 2023 at 17:15, Roland Mainz via Cygwin wrote: > > On Fri, Aug 25, 2023 at 2:18 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 > > I know. > > > 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... > > I think most issues have been fixed for the Microsoft NFSv3 client, > and for the CITI NFSv4.1 client (technically it's called > "ms-nfsv41-client") the situation is even better since it's > opensource, and we can fix problems even faster there. > From what I see the ms-nfsv41-client is stable enough for daily > routine usage, and I know that other institutions like DFG and CERN > use it for daily work too. The only nasty part is the damn lack of > documentation, and that there are no signed binaries, so any kernel > with UEFI/SecureBook cannot use them. > > > Anyway. How would you like to make sure that a Cygwin application > > can differ between real FIFOs and Cygwin FIFOs? > > For now I can provide a migration script, and in the medium term we > should get Microsoft to provide some kind of |mknod()| API. see below. > > > > 2. Check whether the filesystem for the fifos path is NFS > > > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > > > |ENOSYS| (not implemented) > > > > I like the idea. > > See below. > > > > Better algorithm for [1] might be to check whether the inode is a > > > symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|, > > > assuming this is more performant. > > > > Even better would be if we could just create and use real FIFOs > > on NFS(*). But while NtQueryEaFile can be used to fetch real > > NFS file info, and while NtCreateFile can be used to create real > > synmlinks via NFS, I don't see an interface resembling mknod/mkfifo. > > Looking at the ms-nfs41-client source code, there is no API for that *YET*. > > So my plan would be like this: > 1. Cygwin: implements the proposed devnodes-as-symlink emulation code, > if the env var CYGWIN has "nfs_emulate_dev_special_files_as_symlink" > set > 2. Cygwin: By default |mkfifo()| will fail with |ENOSYS| (not |EPERM|, > as we intend to fix the issue!) on NFS filesystems, unless > CYGWIN=nfs_emulate_dev_special_files_as_symlink I think the emulation should be on by default, or you break things. 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Fri, 25 Aug 2023 at 14:26, Corinna Vinschen via Cygwin wrote: > > On Aug 25 14:18, Corinna Vinschen via Cygwin wrote: > > On Aug 23 01:05, Roland Mainz via Cygwin wrote: > > > 2. Check whether the filesystem for the fifos path is NFS > > > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > > > |ENOSYS| (not implemented) > > > > I like the idea. > > EPERM, btw. See https://man7.org/linux/man-pages/man2/mknod.2.html > I am vehemently opposed to that idea. That will IMHO not only be the wrong solution, it will break actual things like autoconf on NFS - they create fifos for testing, but do not use them. If you just make this return EPERM, then you break stuff we have to rely on. mkfifo should just work with Cygwin on NFS. 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
> it is not possible to diffentiate between Cygwin > FIFOs and real FIFOs created from the remote side in `ls -l' > output. Why would that be necessary? If it's a FIFO, it can be used as a FIFO, regardless where and how it was created.. Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Fri, Aug 25, 2023 at 2:18 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 I know. > 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... I think most issues have been fixed for the Microsoft NFSv3 client, and for the CITI NFSv4.1 client (technically it's called "ms-nfsv41-client") the situation is even better since it's opensource, and we can fix problems even faster there. From what I see the ms-nfsv41-client is stable enough for daily routine usage, and I know that other institutions like DFG and CERN use it for daily work too. The only nasty part is the damn lack of documentation, and that there are no signed binaries, so any kernel with UEFI/SecureBook cannot use them. > Anyway. How would you like to make sure that a Cygwin application > can differ between real FIFOs and Cygwin FIFOs? For now I can provide a migration script, and in the medium term we should get Microsoft to provide some kind of |mknod()| API. see below. > > 2. Check whether the filesystem for the fifos path is NFS > > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > > |ENOSYS| (not implemented) > > I like the idea. See below. > > Better algorithm for [1] might be to check whether the inode is a > > symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|, > > assuming this is more performant. > > Even better would be if we could just create and use real FIFOs > on NFS(*). But while NtQueryEaFile can be used to fetch real > NFS file info, and while NtCreateFile can be used to create real > synmlinks via NFS, I don't see an interface resembling mknod/mkfifo. Looking at the ms-nfs41-client source code, there is no API for that *YET*. So my plan would be like this: 1. Cygwin: implements the proposed devnodes-as-symlink emulation code, if the env var CYGWIN has "nfs_emulate_dev_special_files_as_symlink" set 2. Cygwin: By default |mkfifo()| will fail with |ENOSYS| (not |EPERM|, as we intend to fix the issue!) on NFS filesystems, unless CYGWIN=nfs_emulate_dev_special_files_as_symlink 3. (CITI) ms-nfsv41-client: adds a private API to do a |mknod()| 4. Cygwin: Implements the new API added in [3] as *prototype*, so |mknod()| will properly work in a portable manner 5. We ask Microsoft to review the private API created in [3], and ask them to implement it for the Microsoft NFSv3 client too (because we have a precedent with [4]!) Optional: 6. Cygwin: Like [1] add "afs_emulate_dev_special_files_as_symlink" to do the same for AFS 7. Cygwin: Like [2] |mkfifo()| should fail on AFS, unless [6] ... Issues: - [6] and [7] should be decided by the owner of the Microsoft AFS filesystem driver. - Should the new Windows NFS mknod-API be only available for accounts with administrator rights/permissions ? Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&& programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Aug 25 14:18, Corinna Vinschen via Cygwin wrote: > On Aug 23 01:05, Roland Mainz via Cygwin wrote: > > 2. Check whether the filesystem for the fifos path is NFS > > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > > |ENOSYS| (not implemented) > > I like the idea. EPERM, btw. See https://man7.org/linux/man-pages/man2/mknod.2.html 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
Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
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... Anyway. How would you like to make sure that a Cygwin application can differ between real FIFOs and Cygwin FIFOs? > 2. Check whether the filesystem for the fifos path is NFS > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with > |ENOSYS| (not implemented) I like the idea. > Better algorithm for [1] might be to check whether the inode is a > symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|, > assuming this is more performant. Even better would be if we could just create and use real FIFOs on NFS(*). But while NtQueryEaFile can be used to fetch real NFS file info, and while NtCreateFile can be used to create real synmlinks via NFS, I don't see an interface resembling mknod/mkfifo. (*) Not using them in the sense that Cygwin can actually communicate with the real remote FIFO, but in the sense that the fake is good enough so that our fhandler_fifo class can actually utilize the file just like FIFOs on NTFS. 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
Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Thu, 24 Aug 2023 at 18:45, Martin Wege via Cygwin wrote:
>
> On Wed, Aug 23, 2023 at 1:06 AM Roland Mainz via Cygwin
> wrote:
> >
> > On Tue, Aug 22, 2023 at 4:52 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> > via Cygwin wrote:
> > > > FIFOs which don't make *any* sense
> > > > ... FWIW, a remote NFS fileystem.
> > >
> > > I got an impression that the OP is trying to deploy something (maybe the
> > > entire Cygwin) onto an
> > > NFS share. So the named FIFO "file" is also created in there.
> >
> > I agree with that impression. This is basically what large sites
> > (universities etc) do with UNIX and Linux: The machines mount an
> > user's ${HOMR} directory via automounter over NFS, and users are
> > discouraged (e.g. grumpy admin visiting you in person, blocking all
> > escape routes... =:-) ) from using the machine's local filesystems (in
> > Cygwin's case that includes "C:"!).
> >
> > In that case people want to use |mkfifo()|/|mkfifoat()| and/or
> > /usr/bin/mkfifo in their home directory, and don't expect that it does
> > not work.
> >
> > But that is what happens on Cygwin 3.4.8 right now, if someone tries
> > to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and
> > CITI NFSv4 clients):
> > |mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested
> >
> > Example (/cygdrive/h/ is my home directory shared from my Linux machine):
> > snip
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ uname -a
> > CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC
> > x86_64 Cygwin
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ mount
> > C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> > C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> > C:/cygwin64 on / type ntfs (binary,auto)
> > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> > H: on /cygdrive/h type nfs (binary,posix=0,user,noumount,auto)
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ls -l
> > total 1
> > -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> > cygwin_mkfifo_on_nfs.c
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ cat -n cygwin_mkfifo_on_nfs.c
> > 1 #include
> > 2 #include
> > 3 #include
> > 4 #include
> > 5 #include
> > 6 #include
> > 7
> > 8 int main(int ac, char *av[])
> > 9 {
> > 10 (void)puts("# start");
> > 11
> > 12 if
> > (mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) != 0)
> > 13 perror("mkfifo failed");
> > 14 (void)puts("# done.");
> > 15 return EXIT_SUCCESS;
> > 16 }
> > 17
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ gcc -g cygwin_mkfifo_on_nfs.c
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ./a
> > # start
> > # done.
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ ls -l
> > total 68
> > -rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe
> > -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> > cygwin_mkfifo_on_nfs.c
> > lrwxrwxrwx 1 Unix_User+0 Unix_Group+011 Aug 23 00:12 myfifo.fifo
> > -> ':\0:c4:1000'
> >
> > roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> > $ cat > -bash: myfifo.fifo: No such file or directory
> > snip
> >
> > 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.
> > 2. Check whether the filesystem for the fifos path is NFS
> > (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
> > |ENOSYS| (not implemented)
> >
> > Better algorithm for [1] might be to check whether the inode is a
> > symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
> > assuming this is more performant.
>
> We would like to see option 1 implemented,
+1
> maybe as an option in the
> CYGWIN environment variable
> (CYGWIN=nfs_emulate_dev_special_files_as_symlink ?)
+1
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: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Wed, Aug 23, 2023 at 1:06 AM Roland Mainz via Cygwin
wrote:
>
> On Tue, Aug 22, 2023 at 4:52 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
> via Cygwin wrote:
> > > FIFOs which don't make *any* sense
> > > ... FWIW, a remote NFS fileystem.
> >
> > I got an impression that the OP is trying to deploy something (maybe the
> > entire Cygwin) onto an
> > NFS share. So the named FIFO "file" is also created in there.
>
> I agree with that impression. This is basically what large sites
> (universities etc) do with UNIX and Linux: The machines mount an
> user's ${HOMR} directory via automounter over NFS, and users are
> discouraged (e.g. grumpy admin visiting you in person, blocking all
> escape routes... =:-) ) from using the machine's local filesystems (in
> Cygwin's case that includes "C:"!).
>
> In that case people want to use |mkfifo()|/|mkfifoat()| and/or
> /usr/bin/mkfifo in their home directory, and don't expect that it does
> not work.
>
> But that is what happens on Cygwin 3.4.8 right now, if someone tries
> to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and
> CITI NFSv4 clients):
> |mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested
>
> Example (/cygdrive/h/ is my home directory shared from my Linux machine):
> snip
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ uname -a
> CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC
> x86_64 Cygwin
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ mount
> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> H: on /cygdrive/h type nfs (binary,posix=0,user,noumount,auto)
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ ls -l
> total 1
> -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58 cygwin_mkfifo_on_nfs.c
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ cat -n cygwin_mkfifo_on_nfs.c
> 1 #include
> 2 #include
> 3 #include
> 4 #include
> 5 #include
> 6 #include
> 7
> 8 int main(int ac, char *av[])
> 9 {
> 10 (void)puts("# start");
> 11
> 12 if
> (mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) != 0)
> 13 perror("mkfifo failed");
> 14 (void)puts("# done.");
> 15 return EXIT_SUCCESS;
> 16 }
> 17
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ gcc -g cygwin_mkfifo_on_nfs.c
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ ./a
> # start
> # done.
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ ls -l
> total 68
> -rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe
> -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58
> cygwin_mkfifo_on_nfs.c
> lrwxrwxrwx 1 Unix_User+0 Unix_Group+011 Aug 23 00:12 myfifo.fifo
> -> ':\0:c4:1000'
>
> roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
> $ cat -bash: myfifo.fifo: No such file or directory
> snip
>
> 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.
> 2. Check whether the filesystem for the fifos path is NFS
> (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
> |ENOSYS| (not implemented)
>
> Better algorithm for [1] might be to check whether the inode is a
> symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
> assuming this is more performant.
We would like to see option 1 implemented, maybe as an option in the
CYGWIN environment variable
(CYGWIN=nfs_emulate_dev_special_files_as_symlink ?)
Thanks,
Martin
--
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: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Wed, Aug 23, 2023 at 5:44 PM Jeffrey Altman via Cygwin wrote: > > On 8/22/2023 10:52 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin > wrote: > >> FIFOs which don't make *any* sense > >> ... FWIW, a remote NFS fileystem. > > I got an impression that the OP is trying to deploy something (maybe the > > entire Cygwin) onto an NFS share. So the named FIFO "file" is also created > > in there. > > > > It's pointless to assume that the FIFO can be used as a communication > > device between the hosts that can mount the share, but it can be quite > > feasible to envision a scenario, in which the same host opens the FIFO > > located on the share from two processes and establish the communication > > using that special "file" (which is basically a special data-less i-node). > > I've been following this thread with quite a bit of curiosity. For those > who do not know me, I'm the lead developer of the AFS filesystem on > Windows. There have been requests for more than two decades for AFS > clients to add support for locally created pipe files because AFS > volumes are often used as home directories (even on Windows) and so many > applications allocate a pipe in the home directory as a method of > inter-process communication or a lock. The problem is that even if the > intended usage of the file is entirely local, the directory object, the > directory entry and the allocated inode (or equivalent) is network > visible. Who cares? It is up to the user, script or application author to do 'the right thing(tm)'. > > What happens when the user executes two copies of an > application such as PyCharm on two separate machines sharing the same > home directory? Does the directory entry and inode get reused on startup > and/or deleted on exit? How does that impact the process instance on the > other machine? The conclusion I came to long ago is that if pipes are to > be implemented in a network file system namespace then the pipes must be > fully functional network pipes. In just about all cases applications can > be configured to use a non-default paths. In my opinion they should not > be placed in a shared file system. Oh my god. Please have this debate at the Austin Group. They do the POSIX standard. We're here about implementing the POSIX standard. We only want that mkfifo() works with Cygwin on a NFS filesystem, as specified in https://pubs.opengroup.org/onlinepubs/009696799/functions/mkfifo.html My intention was not to invent something new. Just code using mkfifo, and scripts using /usr/bin/mkfifo, should work on NFS. On UNIX this works. Have a look at https://cygwin.com/pipermail/cygwin/2023-August/254266.html, sounds like there is a feasible way to implement this. Thanks, Martin -- 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: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Wed, 23 Aug 2023 at 17:44, Jeffrey Altman via Cygwin wrote: > > On 8/22/2023 10:52 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin > wrote: > >> FIFOs which don't make *any* sense > >> ... FWIW, a remote NFS fileystem. > > I got an impression that the OP is trying to deploy something (maybe the > > entire Cygwin) onto an NFS share. So the named FIFO "file" is also created > > in there. > > > > It's pointless to assume that the FIFO can be used as a communication > > device between the hosts that can mount the share, but it can be quite > > feasible to envision a scenario, in which the same host opens the FIFO > > located on the share from two processes and establish the communication > > using that special "file" (which is basically a special data-less i-node). > > I've been following this thread with quite a bit of curiosity. For those > who do not know me, I'm the lead developer of the AFS filesystem on > Windows. There have been requests for more than two decades for AFS > clients to add support for locally created pipe files because AFS > volumes are often used as home directories (even on Windows) and so many > applications allocate a pipe in the home directory as a method of > inter-process communication or a lock. The problem is that even if the > intended usage of the file is entirely local, the directory object, the > directory entry and the allocated inode (or equivalent) is network > visible. What happens when the user executes two copies of an > application such as PyCharm on two separate machines sharing the same > home directory? Does the directory entry and inode get reused on startup > and/or deleted on exit? How does that impact the process instance on the > other machine? The conclusion I came to long ago is that if pipes are to > be implemented in a network file system namespace then the pipes must be > fully functional network pipes. In just about all cases applications can > be configured to use a non-default paths. In my opinion they should not > be placed in a shared file system. This is NOT what POSIX says. We're talking about mkfifo(), which creates pipes on the local system. The filesystem is just used to use filesystem paths for identification. If you want truly networked fifos, I suggest socket(), preferably with SCTP. But this is OFFTOPIC here. We just want mkfifo() to work on NFS. > > I've also been following this thread because both the Microsoft NFSv3 > and the Citi NFSv4 clients are rather incomplete filesystem > implementations from the perspective of the Installable File System > interface and the Multiple UNC Provider interface. Good. This is actually worth writing a bug report against the CITI NFSv4 client, because the Microsoft NFSv3 client is only extended or fixed if someone is willing to pay a five-digit euro sum to M$. Literally. We asked, and got a longer document describing the expenses. So better fix the NFSv4 client. > In my opinion, > Microsoft NFSv3 is the bare minimum that must be implemented for > Microsoft to advertise that NFSv3 is available on Windows. The NFSv3 > symlink interface leveraging extended attributes as a method of setting > and reading the target predates the introduction of > IO_REPARSE_TAG_SYMLINK for NTFS. Prior to the allocation of > IO_REPARSE_TAG_SYMLINK I obtained a proprietary tag allocation from > Microsoft for AFS symlinks but switched to IO_REPARSE_TAG_SYMLINK once > it was available because then AFS symlinks work the same as NTFS. > > The Citi NFSv4 implementation is not only incomplete from a Windows > interface perspective but Citi never obtained from Microsoft the > required filesystem registrations. Please elaborate > For example, it doesn't have a > Microsoft assigned FLT_FILESYSTEM_TYPE, WNNC network type, name or > NodeTypeCode values. FLT_FSTYPE_NFS, WNNC_NET_MS_NFS, and "nfs" are > specific to the Microsoft NFSv3 (aka \FileSystem\NfsRdr) implementation. This is not correct. The CITI NFSv4 client was originally written using $$$ from a grant from Microsoft, and is intended to be a drop-in replacement for the NFSv3 client. Hence it shares the same "nfs" name, uses the same extension apis (fsattr3), and should behave almost the same. > The NodeTypeCode range used by the Citi NFSv4 filesystem (0xFC00) is > outside the block allocated to third party filesystems and appears to be > from a published sample which could lead to corruption if two > filesystems allocating FileControlBlocks with the same NodeTypeCodes are > present on the system. The returned WNNC value is also from a sample. Please file a bug report. This should be fixable. > Perhaps the original poster knows where development of the Citi NFSv4 > client is currently taking place. The source code repos I've been able > to find do not have any commits since 2012 (tag v1.0.0) and have been > flagged as archival on GitHub. Seriously just my personal opinion, not speaking for my employer: 2013 on the github, and the DFG (Deutsche Forschungs
RE: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
> What happens when the user executes two copies of an > application /*such as PyCharm*/ on two separate machines sharing the same > home directory? Does the directory entry and inode get reused on startup > and/or deleted on exit? How does that impact the process instance on the > other machine? The conclusion I came to long ago is that if pipes are to > be implemented in a network file system namespace then the pipes must be > fully functional network pipes. A p-type i-node (FIFO on Unix) is a local named pipe regardless of its location. Two pairs of applications running on two different hosts that happen to mount the same network share, do not have to "know" of each other, the i-node is only used to identify the FIFO within the namespace of the same node. So both pairs can actually be communicating locally within their respective nodes, without affecting one another, between the processes within that same node. Deleting / creating a FIFO has no significance, as it's just an i-node to "name" the pipe (via the i-node number). Unlike UNIX sockets (which too can be placed on network shares, BTW), FIFO files do not need to be re-created afresh every time they are used. The only requirement is that the same i-node is opened for both reading and writing, and that's all it is necessary to create a communication channel: "man 7 fifo". Someone wanting a truly networking device should be using sockets. Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On 8/22/2023 10:52 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: FIFOs which don't make *any* sense ... FWIW, a remote NFS fileystem. I got an impression that the OP is trying to deploy something (maybe the entire Cygwin) onto an NFS share. So the named FIFO "file" is also created in there. It's pointless to assume that the FIFO can be used as a communication device between the hosts that can mount the share, but it can be quite feasible to envision a scenario, in which the same host opens the FIFO located on the share from two processes and establish the communication using that special "file" (which is basically a special data-less i-node). I've been following this thread with quite a bit of curiosity. For those who do not know me, I'm the lead developer of the AFS filesystem on Windows. There have been requests for more than two decades for AFS clients to add support for locally created pipe files because AFS volumes are often used as home directories (even on Windows) and so many applications allocate a pipe in the home directory as a method of inter-process communication or a lock. The problem is that even if the intended usage of the file is entirely local, the directory object, the directory entry and the allocated inode (or equivalent) is network visible. What happens when the user executes two copies of an application such as PyCharm on two separate machines sharing the same home directory? Does the directory entry and inode get reused on startup and/or deleted on exit? How does that impact the process instance on the other machine? The conclusion I came to long ago is that if pipes are to be implemented in a network file system namespace then the pipes must be fully functional network pipes. In just about all cases applications can be configured to use a non-default paths. In my opinion they should not be placed in a shared file system. I've also been following this thread because both the Microsoft NFSv3 and the Citi NFSv4 clients are rather incomplete filesystem implementations from the perspective of the Installable File System interface and the Multiple UNC Provider interface. In my opinion, Microsoft NFSv3 is the bare minimum that must be implemented for Microsoft to advertise that NFSv3 is available on Windows. The NFSv3 symlink interface leveraging extended attributes as a method of setting and reading the target predates the introduction of IO_REPARSE_TAG_SYMLINK for NTFS. Prior to the allocation of IO_REPARSE_TAG_SYMLINK I obtained a proprietary tag allocation from Microsoft for AFS symlinks but switched to IO_REPARSE_TAG_SYMLINK once it was available because then AFS symlinks work the same as NTFS. The Citi NFSv4 implementation is not only incomplete from a Windows interface perspective but Citi never obtained from Microsoft the required filesystem registrations. For example, it doesn't have a Microsoft assigned FLT_FILESYSTEM_TYPE, WNNC network type, name or NodeTypeCode values. FLT_FSTYPE_NFS, WNNC_NET_MS_NFS, and "nfs" are specific to the Microsoft NFSv3 (aka \FileSystem\NfsRdr) implementation. The NodeTypeCode range used by the Citi NFSv4 filesystem (0xFC00) is outside the block allocated to third party filesystems and appears to be from a published sample which could lead to corruption if two filesystems allocating FileControlBlocks with the same NodeTypeCodes are present on the system. The returned WNNC value is also from a sample. Perhaps the original poster knows where development of the Citi NFSv4 client is currently taking place. The source code repos I've been able to find do not have any commits since 2012 (tag v1.0.0) and have been flagged as archival on GitHub. In my opinion, for Cygwin to reliably work with either of these implementations is going to require on-going developer effort and continuous integration testing. Not only of Cygwin but in the case of Citi NFSv4 from the team maintaining the product. Unless something has significantly changed since 2013 I do not expect Microsoft to be willing to invest much effort into enhancing the NFSv3 implementation. The likely recommendation would be to re-export the NFS file shares via Samba and access them via CIFS. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature -- 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
How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
On Tue, Aug 22, 2023 at 4:52 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C]
via Cygwin wrote:
> > FIFOs which don't make *any* sense
> > ... FWIW, a remote NFS fileystem.
>
> I got an impression that the OP is trying to deploy something (maybe the
> entire Cygwin) onto an
> NFS share. So the named FIFO "file" is also created in there.
I agree with that impression. This is basically what large sites
(universities etc) do with UNIX and Linux: The machines mount an
user's ${HOMR} directory via automounter over NFS, and users are
discouraged (e.g. grumpy admin visiting you in person, blocking all
escape routes... =:-) ) from using the machine's local filesystems (in
Cygwin's case that includes "C:"!).
In that case people want to use |mkfifo()|/|mkfifoat()| and/or
/usr/bin/mkfifo in their home directory, and don't expect that it does
not work.
But that is what happens on Cygwin 3.4.8 right now, if someone tries
to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and
CITI NFSv4 clients):
|mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested
Example (/cygdrive/h/ is my home directory shared from my Linux machine):
snip
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ uname -a
CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC
x86_64 Cygwin
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
H: on /cygdrive/h type nfs (binary,posix=0,user,noumount,auto)
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ ls -l
total 1
-rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58 cygwin_mkfifo_on_nfs.c
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ cat -n cygwin_mkfifo_on_nfs.c
1 #include
2 #include
3 #include
4 #include
5 #include
6 #include
7
8 int main(int ac, char *av[])
9 {
10 (void)puts("# start");
11
12 if
(mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) != 0)
13 perror("mkfifo failed");
14 (void)puts("# done.");
15 return EXIT_SUCCESS;
16 }
17
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ gcc -g cygwin_mkfifo_on_nfs.c
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ ./a
# start
# done.
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ ls -l
total 68
-rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe
-rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58 cygwin_mkfifo_on_nfs.c
lrwxrwxrwx 1 Unix_User+0 Unix_Group+011 Aug 23 00:12 myfifo.fifo
-> ':\0:c4:1000'
roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs
$ cat ':\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.
2. Check whether the filesystem for the fifos path is NFS
(cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
|ENOSYS| (not implemented)
Better algorithm for [1] might be to check whether the inode is a
symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
assuming this is more performant.
> It's pointless to assume that the FIFO can be used as a communication
> device between the hosts that can mount the share, but it can be quite
> feasible to envision a scenario, in which the same host opens the FIFO
> located on the share from two processes and establish the
> communication using that special "file" (which is basically a special
> data-less i-node).
Well, this is what RFS (see
https://en.wikipedia.org/wiki/Remote_File_Sharing) was doing - but it
was removed in Solaris 2.4, because its complexity was too great
(well, the original implementation was simple and clean, and then it
grew all over the kernel just to handle all corner cases of POSIX)
- and it would be nice not to repeat the mistakes of the past.
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&& programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
--
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: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
> FIFOs which don't make *any* sense > ... FWIW, a remote NFS fileystem. I got an impression that the OP is trying to deploy something (maybe the entire Cygwin) onto an NFS share. So the named FIFO "file" is also created in there. It's pointless to assume that the FIFO can be used as a communication device between the hosts that can mount the share, but it can be quite feasible to envision a scenario, in which the same host opens the FIFO located on the share from two processes and establish the communication using that special "file" (which is basically a special data-less i-node). Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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
