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
