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

[Jeffrey Altman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4085 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://cygwin.com/pipermail/cygwin/attachments/20230823/8cfe2767/attachment.p7s>