[EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
Wed Aug 23 15:43:20 GMT 2023
On 8/22/2023 10:52 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4085 bytes
Desc: S/MIME Cryptographic Signature
More information about the Cygwin