From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 2B0133858C53 for ; Thu, 24 Aug 2023 05:30:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B0133858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so1090864a12.0 for ; Wed, 23 Aug 2023 22:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692854998; x=1693459798; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GHE4b1efywpq5/oQngYfowEHPNOyEKeKNEt/eFaNqCM=; b=UQ+Ka4Chqy5CbZU5iqwkw6QS+zXec7Mix7Bk9gP4qbXl2m9FyEbxZ3v0QlNOEQOJKd TRQKVnPVwCppGvQYSIJMQXEIOGow8wcrJqIz85iLyHmVE4Vw9iOvOz1IehRQonkqQw// 3+3kNad7NvWLRbnQCHmupBTkeprCReu7YNC2LR4xjFXA1iWFy7ASBaWJzd64/WGoINHO /l/PET+mch2MguPXTq/5huLpQy7MRXNovexAAxpQNyN2GEiN+ZzX/gky/Sz0RFuzaf5Q 40sRwfQlm5evFg+j+VgB8lCCYwQJZrlSj1B4R9fPubZK/IO9eNgOo/vfM6Ym3c/QJ71U mRsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692854998; x=1693459798; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GHE4b1efywpq5/oQngYfowEHPNOyEKeKNEt/eFaNqCM=; b=FDc/pyxgyZj1XPSiAk4eM/O5BiZzox1f+nHXUKQGYwKsDq4mizDhh22XkcqZ1kTs7Y AGjhYjdARw7WB0PwKHDuEeuqbGXk1wwNP/3La2UYl8QuSpghhlC1B/3L5r+A1Q3baXwb 832d7febF5A7wPNHRlEAqPYskaDuBIqSHTash0MyH3J8QNiPIDX0MKpEm8HPa9Z6UBTY g/4Q+RDIJ3mtR9bm79mxna92c8zn6UMTzPXaCw/qfg0EpzrSRmq+nFhyZfFFuxKjPuQw Zd3+/HbZ7XgoDTgo9DlibKGC9nwPZEWqlz6YSnhZpLGMddsnq6bNXPOcDsorzPo+6Kn+ MwHQ== X-Gm-Message-State: AOJu0YwwA50t4oZSYjX7+PE0/NbfuNpcZHuL77VqmYUVNTQjiiJadt73 miZgGKyiEuW0/1scKtp/tz+g8hl0PX0KyNlkouRQv0uFaUgnxQ== X-Google-Smtp-Source: AGHT+IE/5gL5GBVNbyLz2KsxXQq3xRQTM238gXQPabC8SHR2WEXvbFgua3aqDmnDw8CToJriNjUniU/L80azUjoDrPU= X-Received: by 2002:a05:6402:430f:b0:527:1855:be59 with SMTP id m15-20020a056402430f00b005271855be59mr16278550edc.3.1692854998187; Wed, 23 Aug 2023 22:29:58 -0700 (PDT) MIME-Version: 1.0 References: <14a692f6-7244-4a7e-a69b-d14521fb01e8@secure-endpoints.com> In-Reply-To: <14a692f6-7244-4a7e-a69b-d14521fb01e8@secure-endpoints.com> From: Cedric Blancher Date: Thu, 24 Aug 2023 07:28:00 +0200 Message-ID: Subject: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 th= e entire Cygwin) onto an NFS share. So the named FIFO "file" is also creat= ed in there. > > > > It's pointless to assume that the FIFO can be used as a communication d= evice between the hosts that can mount the share, but it can be quite feasi= ble to envision a scenario, in which the same host opens the FIFO located o= n the share from two processes and establish the communication using that s= pecial "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 --=20 Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur