Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory

[Cedric Blancher <cedric.blancher@gmail.com>]

On Wed, 23 Aug 2023 at 17:44, Jeffrey Altman via Cygwin
<cygwin@cygwin.com> 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 Gemeinschaft) has
an ongoing fork since 2019, more or less the same year M$ came up with
the insane cost estimate for "fixing" their own horrible NFSv3 client.
Basically their retaliation to M$ wanting money for broken things. The
hard part is now to get them to throw the patches over the fence, get
them reviewed and tested.

Also, I don't like that you hit on the CITI NFSv4 client work. It is
good and stable enough for routine cluster usage, and much faster than
Microsoft's own NFSv3 client. There are issues, but none which happen
in said environment.

The only REAL issue is the lack of public binaries with signed
binaries, as any self-compiled ones cannot be loaded into a Windows
kernel with SecureBoot enabled.

>
> 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.

I don't want to bash, or rant about CIFS, but getting CIFS into
embedded medical devices is a security nightmare. I know, we tried,
and seriously ended up with both the Linux NFSv4 kernel client, and
the NFS4j for JAVA standalone applications.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur