From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) by sourceware.org (Postfix) with ESMTPS id B8C153858D37 for ; Tue, 22 Aug 2023 23:06:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B8C153858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nrubsig.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-io1-f45.google.com with SMTP id ca18e2360f4ac-79243040c2cso56850039f.1 for ; Tue, 22 Aug 2023 16:06:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692745563; x=1693350363; 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=suE9etNBtpAe0tussga90Le18hxiwWkjpFCZ5MMzxpg=; b=TgriBoscNz3zUJE2M9cHvvh4RcA7NMn+39JpK2sOFlCGMuLivcf+xFJ/YhVrX9O/w8 Zc6CwI6k6uNC+3oMHnORnX3GMdoGul/hhSY0v2jOfDFraY0ak0/EcgzBRKEKJzX8gM89 jl/txDNdoSIua+MLab+p0KEscr1cnUiyh1Huymv8z7ffqBFPSar4YOM4HW5OziTX9W4w BYdx5d9xIkhrYWed5bbYtKrtv7rwCpOWGJJrBWapuSlwvvATx+4r+kwwmL8x2LtJDKCl mL2D5uKqnUtwZ9d+SiyoEyECdSYX3mFDYZjoUhr7Euf41xh2y/cJWqTDiR2/XgxYxIS8 t0+g== X-Gm-Message-State: AOJu0YxFc6Wa0RUBqfsWR0hO0rx+DfsArFauuGNlNJpuohGNH/unvz6d 1Wn2vuyyfpo10KrxqrphFCmDnyE+PZFXRpR44BuQoaE2sN0= X-Google-Smtp-Source: AGHT+IGOEVYo6BNqSwdjwzh0nb5JCXXQHKgO1EEVlEKkLCnKs5St0F5kFK7YmMqVw0PpBQxY/AQofDReeLJmMorQrxE= X-Received: by 2002:a6b:620d:0:b0:786:f4a0:d37e with SMTP id f13-20020a6b620d000000b00786f4a0d37emr1095446iog.4.1692745562584; Tue, 22 Aug 2023 16:06:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roland Mainz Date: Wed, 23 Aug 2023 01:05:36 +0200 Message-ID: Subject: How to fix |mkfifo()| failure if |pathname| is on NFS ? / was: 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=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Tue, Aug 22, 2023 at 4:52=E2=80=AFPM 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. I agree with that impression. This is basically what large sites (universities etc) do with UNIX and Linux: The machines mount an user's ${HOMR} directory via automounter over NFS, and users are discouraged (e.g. grumpy admin visiting you in person, blocking all escape routes... =3D:-) ) from using the machine's local filesystems (in Cygwin's case that includes "C:"!). In that case people want to use |mkfifo()|/|mkfifoat()| and/or /usr/bin/mkfifo in their home directory, and don't expect that it does not work. But that is what happens on Cygwin 3.4.8 right now, if someone tries to do a |mkfifo()| on a NFS home directory (tested with MS NFSv3 and CITI NFSv4 clients): |mkfifo()| succeeds, but the resulting inode is *NOT* a FIFO as requested Example (/cygdrive/h/ is my home directory shared from my Linux machine): ---- snip ---- roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ uname -a CYGWIN_NT-10.0-19045 winkrakra1 3.4.8-1.x86_64 2023-08-17 17:02 UTC x86_64 Cygwin roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=3D0,user,noumount,auto) H: on /cygdrive/h type nfs (binary,posix=3D0,user,noumount,auto) roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ ls -l total 1 -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58 cygwin_mkfifo_on_nfs= .c roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ cat -n cygwin_mkfifo_on_nfs.c 1 #include 2 #include 3 #include 4 #include 5 #include 6 #include 7 8 int main(int ac, char *av[]) 9 { 10 (void)puts("# start"); 11 12 if (mkfifo("/cygdrive/h/work/cygwin_mkfifo_on_nfs/myfifo.fifo", 0) !=3D 0) 13 perror("mkfifo failed"); 14 (void)puts("# done."); 15 return EXIT_SUCCESS; 16 } 17 roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ gcc -g cygwin_mkfifo_on_nfs.c roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ ./a # start # done. roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ ls -l total 68 -rwxr-xr-x 1 Unix_User+0 Unix_Group+0 66951 Aug 23 00:12 a.exe -rw-rw-rw- 1 Unix_User+0 Unix_Group+0 330 Aug 22 23:58 cygwin_mkfifo_on_n= fs.c lrwxrwxrwx 1 Unix_User+0 Unix_Group+0 11 Aug 23 00:12 myfifo.fifo -> ':\0:c4:1000' roland_mainz@winkrakra1 /cygdrive/h/work/cygwin_mkfifo_on_nfs $ cat ':\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. 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) 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. > 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). Well, this is what RFS (see https://en.wikipedia.org/wiki/Remote_File_Sharing) was doing - but it was removed in Solaris 2.4, because its complexity was too great (well, the original implementation was simple and clean, and then it grew all over the kernel just to handle all corner cases of POSIX&co.) - and it would be nice not to repeat the mistakes of the past. ---- Bye, Roland --=20 __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /=3D=3D\ O\ TEL +49 641 3992797 (;O/ \/ \O;)