X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 527853858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1692965922;
	bh=5gj2Ogv7tr0JIlwT2B+Vt8o7755pBzfS7pzFRkcweWc=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=NPIAHm46BMRXvX/5B+OFVuaNeV8cZ0cfC799CfvGUOwGU/rxI5tkZANeatbl3bp7W
	 oXpWqrlQfzHNKwDV4qKWnz/4PgS5eMbeTKei7JcPXTAl6KN13dgGob5QGkaIFFN2qi
	 Myp8YcqlTUYygET7gszIo5VixAMhnrogBT74GdBs=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A5C03858C53
Date: Fri, 25 Aug 2023 14:18:23 +0200
To: cygwin AT cygwin DOT com
Subject: Re: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was:
 Re: [EXTERNAL] Re: mkfifo: cannot set permissions of 'x.fifo': Not a
 directory
Message-ID: <ZOicD/nxECrAPnKV@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CANH4o6O-8O-iMaHowDuy0y7H=pVfZ-3EvubDmTdjGVSST8FkAQ AT mail DOT gmail DOT com>
 <CANH4o6MnH7gWj7d0vmkhCL5N0BTbkrbtGZGtso43MVZBJLBGtw AT mail DOT gmail DOT com>
 <ZN8tK/mATx6KbQWk AT calimero DOT vinschen DOT de>
 <CALXu0UcByeJHfBWSPEZkmfMqSKkmRT_5ZkxLc25EyhJzN9FUtA AT mail DOT gmail DOT com>
 <ZOMiYcQfb7i8Kc8i AT calimero DOT vinschen DOT de>
 <DM8PR09MB70950FABA8C4DAD80B0EA189A51FA AT DM8PR09MB7095 DOT namprd09 DOT prod DOT outlook DOT com>
 <CAKAoaQkPovkZhVVnkDB3wXKdHejqwKmG7vG38rfy2rtjsGV-uQ AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKAoaQkPovkZhVVnkDB3wXKdHejqwKmG7vG38rfy2rtjsGV-uQ@mail.gmail.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Aug 23 01:05, Roland Mainz via Cygwin wrote:
> Note that Cygwin does not interpret the file |myfifo.fifo| as FIFO,
> instead it comes back as a symlink "myfifo.fifo -> ':\0:c4:1000'".
> 
> AFAIK there are (at least) these two options to fix the problems:
> 1. Check whether the filesystem for the fifos path is NFS
> (cgywin.dll's |fs.fs_is_nfs()|), and if it is a symlink check if it
> starts with ':\0:c4:' (assuming "c4" is the prefix for inodes created
> with |mkfifo()|). If this condition is |true|, then cygwin |stat()|,
> |open()| etc. should treat this inode as FIFO.

The downside is that it is not possible to diffentiate between Cygwin
FIFOs and real FIFOs created from the remote side in `ls -l'
output.  Note that Cygwin returns the NFS stat info verbatim, so
a real FIFO is returned as a real FIFO:

  linux$ mkfifo bar
  cygwin$ ls -l bar
  prw-r--r-- 1 corinna vinschen  0 Aug 25 13:58 bar

The idea was always to use NFS as exchange medium, but not as
installation medium for the entire distro or to keep Cygwin home
dirs on NFS.  There were times where NFS was pretty unstable.
I used NFS for quite some time to build Cygwin packages, but at one
point I got trouble (performance problems with multiple concurrent
processes accessing an NFS share, build errors out of the blue),
so I switched to Samba shares, albeit grudgingly.  I'm not yet
sure if the problems are fixed.  At least a recent OpenSSH build
ran through without problems...

Anyway.  How would you like to make sure that a Cygwin application
can differ between real FIFOs and Cygwin FIFOs?

> 2. Check whether the filesystem for the fifos path is NFS
> (cgywin.dll's |fs.fs_is_nfs()|), and then just refuse |mkfifo()| with
> |ENOSYS| (not implemented)

I like the idea.

> Better algorithm for [1] might be to check whether the inode is a
> symlink, and then do a |fs.fs_is_nfs()| on the symlinks |pathname|,
> assuming this is more performant.

Even better would be if we could just create and use real FIFOs
on NFS(*).  But while NtQueryEaFile can be used to fetch real
NFS file info, and while NtCreateFile can be used to create real
synmlinks via NFS, I don't see an interface resembling mknod/mkfifo.

(*) Not using them in the sense that Cygwin can actually communicate
with the real remote FIFO, but in the sense that the fake is good enough
so that our fhandler_fifo class can actually utilize the file just like
FIFOs on NTFS.


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple