public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Martin Wege <martin.l.wege@gmail.com>
To: cygwin@cygwin.com
Subject: Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a directory
Date: Thu, 24 Aug 2023 18:40:29 +0200	[thread overview]
Message-ID: <CANH4o6Ozqq7vSqRv+-PLVWcSDToh3WbJ9_E9obm-7R_6WNz5mw@mail.gmail.com> (raw)
In-Reply-To: <14a692f6-7244-4a7e-a69b-d14521fb01e8@secure-endpoints.com>

On Wed, Aug 23, 2023 at 5:44 PM 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.

Who cares? It is up to the user, script or application author to do
'the right thing(tm)'.

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

Oh my god. Please have this debate at the Austin Group. They do the
POSIX standard. We're here about implementing&using the POSIX
standard.

We only want that mkfifo() works with Cygwin on a NFS filesystem, as
specified in https://pubs.opengroup.org/onlinepubs/009696799/functions/mkfifo.html

My intention was not to invent something new. Just code using mkfifo,
and scripts using /usr/bin/mkfifo, should work on NFS. On UNIX&Linux
this works.

Have a look at https://cygwin.com/pipermail/cygwin/2023-August/254266.html,
sounds like there is a feasible way to implement this.

Thanks,
Martin

  parent reply	other threads:[~2023-08-24 16:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 14:42 Martin Wege
2023-08-07 18:26 ` Brian Inglis
2023-08-07 19:14   ` Corinna Vinschen
2023-08-07 21:14     ` Martin Wege
2023-08-08  8:20       ` Corinna Vinschen
2023-08-08 19:38         ` Martin Wege
2023-08-09  8:01           ` Corinna Vinschen
2023-08-09  9:12             ` Martin Wege
2023-08-09  9:56               ` Corinna Vinschen
2023-08-10 12:49                 ` Martin Wege
2023-08-18  4:02 ` Martin Wege
2023-08-18  8:34   ` Corinna Vinschen
2023-08-18 13:14     ` Martin Wege
2023-08-21  4:49     ` Cedric Blancher
2023-08-21  8:37       ` Corinna Vinschen
2023-08-22 14:52         ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-08-22 23:05           ` How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: " Roland Mainz
2023-08-24 16:45             ` Martin Wege
2023-08-25  4:25               ` Cedric Blancher
2023-08-26 17:58               ` Martin Wege
2023-08-25 12:18             ` Corinna Vinschen
2023-08-25 12:25               ` Corinna Vinschen
2023-08-26 11:26                 ` Cedric Blancher
2023-08-26 14:15                   ` Corinna Vinschen
2023-08-26 17:40                     ` Martin Wege
2023-08-26 19:16                       ` Brian Inglis
2023-08-25 15:14               ` Roland Mainz
2023-08-26 11:27                 ` Cedric Blancher
2023-08-25 23:21               ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-08-26 14:28                 ` Corinna Vinschen
2023-08-26 14:39                   ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-08-26 17:44               ` Documenting Cygwin on NFS, no longer only exchange-medium! " Martin Wege
2023-08-26 19:16                 ` Brian Inglis
2023-08-27 12:35                 ` Corinna Vinschen
2023-08-28  5:35                   ` Cedric Blancher
2023-08-28 10:02                     ` Corinna Vinschen
2023-08-28 11:41                   ` Joshuah Hurst
     [not found]           ` <14a692f6-7244-4a7e-a69b-d14521fb01e8@secure-endpoints.com>
2023-08-23 17:39             ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-08-24  5:28             ` Cedric Blancher
2023-08-24 16:40             ` Martin Wege [this message]
2023-08-21 12:12     ` Martin Wege

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANH4o6Ozqq7vSqRv+-PLVWcSDToh3WbJ9_E9obm-7R_6WNz5mw@mail.gmail.com \
    --to=martin.l.wege@gmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).