From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 2DD9E3858C53; Fri, 25 Aug 2023 04:26:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DD9E3858C53 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-lf1-x12a.google.com with SMTP id 2adb3069b0e04-4fe27849e6aso715280e87.1; Thu, 24 Aug 2023 21:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692937589; x=1693542389; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3Mk01K3T8aygqyZQleYn3noyrh/DoMyF3iLHh26D07w=; b=jYwm1jcLVggHSTG05AmNJWZkSkAmow5a8fJrY3FrsGaafy7B96fHEjPjpZPlKURBzJ MCIwC1RNER/TKXDAsK1HEGO/FraIPOgwsWiS4NCrrbtQVnfDq/7W9eTmNdMQiJL3pP94 rNL6LIXrEr+9/Z5VhOnzUhx7Fd4TzTj8+LABmFqylJUz775DiVLj9j1tBTCILT+fV4oF 91f4ALLmCfakoPukXJrw8IsCe8uKDn4zCIBMcImSFdSljOLTxeun3aJDOR798TD1RCT7 Pu1IUlq+yG/4iUwc/HUudabS2QncWNIua5bjadfkrk7QyLb7cVtxhyRkB7S17tHSlEi4 Ex5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692937589; x=1693542389; h=content-transfer-encoding:cc: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=3Mk01K3T8aygqyZQleYn3noyrh/DoMyF3iLHh26D07w=; b=l2LwkM6vpoEVjBJPFRATvYoCKH6MdUbV+MXygqVcd26x/O5InFsxCFSbi/Mk2BVorz o2yhFpDMb4X4UlM3oMi8M213iqJONXHoge27yZO1Sixx9UPc9xbck4/JdheZwYaPv64i X+zS0qtEv6WDl827XMyFgQapUPG9csvE7nG5pZaMbOYUki1Dt/pvImuGeN+wNw9yUEA5 dRSmDAiqTu6r0/c/5SUi7gTQZY/DmtGiZaKAIG78VbJeOWKcrX6Xvvo0mcr+sbBDl5no GzrXUUTc9xfSHRylFLNEzz09PsfPfvKwEayOfzRCwXRQUHtQU62aZ+KpSR7obmiWwKtY CgMg== X-Gm-Message-State: AOJu0YwD2UnHKjn4lxxeRc9fzr1iM8MZnRGV9br2dn/XcyuCtEaIZNt9 Heojj+W8DrfpWnaB6tH2m55ZQ1cem7+RfKrRj1kpVLbHt2Z2LA== X-Google-Smtp-Source: AGHT+IE0bCknT3s116TT4bYg+nnjUivLRFAsRHOw9e3qdUL3vm9gqnDSeWXUF3rcoGckqw1U8uz/9sWL61OzfsvovsI= X-Received: by 2002:a19:6552:0:b0:500:7e70:ddf7 with SMTP id c18-20020a196552000000b005007e70ddf7mr9869775lfj.52.1692937589255; Thu, 24 Aug 2023 21:26:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cedric Blancher Date: Fri, 25 Aug 2023 06:25:00 +0200 Message-ID: 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 To: Martin Wege Cc: "cygwin@cygwin.com" , Corinna Vinschen 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 Thu, 24 Aug 2023 at 18:45, Martin Wege via Cygwin wr= ote: > > On Wed, Aug 23, 2023 at 1:06=E2=80=AFAM Roland Mainz via Cygwin > wrote: > > > > 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 (i= n > > 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 request= ed > > > > 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_nfs.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 > -bash: myfifo.fifo: No such file or directory > > ---- snip ---- > > > > 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. > > 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. > > We would like to see option 1 implemented, +1 > maybe as an option in the > CYGWIN environment variable > (CYGWIN=3Dnfs_emulate_dev_special_files_as_symlink ?) +1 Ced --=20 Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur