From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by sourceware.org (Postfix) with ESMTPS id 141FC3857704 for ; Thu, 24 Aug 2023 16:40:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 141FC3857704 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-oa1-x36.google.com with SMTP id 586e51a60fabf-1c4d8eaa8ebso13566fac.0 for ; Thu, 24 Aug 2023 09:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692895240; x=1693500040; 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=0sJgU04zsZmAxUdzbhmL3CiaZZtuwVv3fT5YmhJrhus=; b=XA2de6tYH8IQ6ke6O9z9ZpiJCqtmt4Ehp9VZAAryjMyz7/iGl3fG1kThXEqsbJl3gW mtPhNdKmdIPYrUSZwrQZbnJ/UxiltXDh+BDMBxcyScN5DvsdpnwkSTMlzRAiZXx95uOa ZUNq/nwKzcPqf/YAd+gASgmWlHYKOZggl+/knoGmTGp2TfUyaa4LP9ndrfV28K25LisS jVpCN8sR5pkUmQSSSxix8s2FHJVH810ZT4KQa16UVo+uZrJnegXXyxi10LBvCsGS4iti FfwlBfB1RYL71Hd0NLmu/9g3MRCujXAbdkSUjuMAG8ZJVfvHAbEyAq/TOKv5gvnJU/8i dVxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692895240; x=1693500040; 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=0sJgU04zsZmAxUdzbhmL3CiaZZtuwVv3fT5YmhJrhus=; b=SJj7mEjkFSLrc4UFs56U3qAXL30fDNrCU8ROlsd6cmE3tNZCbd8EenE/MTV1XIxJLu dGo1kNIm0l69R+L5nbfLKKmtYn9FKvAnzOTHEvI98v1E4j3KJC7Q8yw+eSnUnbl/GVrg MOeChCX+7ZhS81MfSFyE0KUiPndHfsnS06FQuylSlUUEfTsSONLvA0qf/3f2K7NxoKLD u1+qjKZJZRo/aM39IdbJfl/jHJUONBgKsPOWVRYxQDC5Nm5HRNnQKyXsWBxuCjWvjl/5 lgPacAxZAIHUI6lf1K27tsUn6Xo+YUt6aVi7+nHT8ao+EltCoDv97+5tIDSmx3RQ2JCC mHfA== X-Gm-Message-State: AOJu0Yxl/yGWZr3AZAihlW9WGEYTDNwXsZGXofKGTLEgK02CEI2Ry5yP QhxygRyz3gQDMTFhjcFuN6p7uZA4dpJE9FmaWqmUp0B0/fBHqSV9 X-Google-Smtp-Source: AGHT+IGHTKoLWLDms+dt2pfzavV9QuFUvfGwzUAnz2fEwZY+5tW1nG0bI5QJqqUZ4mI68Qx1DeuEvaA1saAv2pFrfdE= X-Received: by 2002:a05:6870:63a8:b0:1be:e066:acc with SMTP id t40-20020a05687063a800b001bee0660accmr348928oap.50.1692895240220; Thu, 24 Aug 2023 09:40:40 -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: Martin Wege Date: Thu, 24 Aug 2023 18:40:29 +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.4 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, Aug 23, 2023 at 5:44=E2=80=AFPM 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. 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/mkfi= fo.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