From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) by sourceware.org (Postfix) with ESMTPS id 805863858C53; Sat, 26 Aug 2023 17:58:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 805863858C53 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-oo1-xc33.google.com with SMTP id 006d021491bc7-5732481b22eso1305780eaf.3; Sat, 26 Aug 2023 10:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693072708; x=1693677508; 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=U3JmvJeF98Er3eytDBR/+CgBuhBS2P+jaN1+Pd325FQ=; b=FIlKJ7x7I+yioRCmJlLrruvZHZggubnlVuQvYOopiSoTYS3Unbv4nu5p9AfeeJN9Hv t7S+xQvxKz7/PVzFAVHDgkUE6RqXVZLKccp7+19GsNku9TWFy1OwT4yJ0brredIQ/RXx qwGer7bm+hIbUfkm64wkc+Sdt0b4Y3zbE8seLdHXV4al1wck/iCTZVJHcTppjWQa007q VLRAlI4Fcc4vitGxk6D3402GEJbW7qhZLOPLFCRSqHDsU6LqE58btW7gFGLX99WmjEKM OXaAhWcPrgzyHpSAnSQ/zRx0Mls1BydwfIyXazW5klM8jfhk4l5ZIttn6qzUp4reCuHr THww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693072708; x=1693677508; 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=U3JmvJeF98Er3eytDBR/+CgBuhBS2P+jaN1+Pd325FQ=; b=ePsB1c/7W0t/Lpt1zq+u5afaieR/Y8wYo3VA3p5hGiusjJFvuPQcnJY0HInhB8Cyxx vl2lOHUzcueuuz6/SNWT29T9TUJt2/HtDyp8X3VXABCMhbQ8yxqPGsqkbIOdIcpH3V8I ryzp/eoxUOWiqbCI552HlpbpBRFpL43XoIovU/vsPaweljevimzHMm0NpXd5dNSxE5cw VdzkEB107oC+Xwo0TJBgOsS6Z1wBtF7IlqFWdx6YFBBwmLTAj1jfeL+YeNOLj3x38M/U I6GC9HGkY/8brNkjDz76EPoiLPBdhcMfeqf3I6CjUpYV+Gf/FjW/qnBcdDA/RbvI+b47 7reA== X-Gm-Message-State: AOJu0YxVFsQB1j0mAmoH1NBcfYi5M5yu5r0/UYewjj3oPOS4Y9+oSWCE u5a5Wtj8beHPDgL30HHfMfx1Qt/0hM2QAhd5KEX7ZjL6I8YHhKha X-Google-Smtp-Source: AGHT+IGCOpV6wuHpuM9EgK+PenJD93ozNTjGuCXfOvp2/jGwX80ompZz2YwQvpSPY5PYj2gqOao4pvnid+ekuKkBLQI= X-Received: by 2002:a4a:755c:0:b0:571:1fad:ebdf with SMTP id g28-20020a4a755c000000b005711fadebdfmr7746386oof.4.1693072708378; Sat, 26 Aug 2023 10:58:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Wege Date: Sat, 26 Aug 2023 19:58:17 +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: "cygwin@cygwin.com" , Corinna Vinschen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.7 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, Aug 24, 2023 at 6:45=E2=80=AFPM Martin Wege wrote: > > 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, maybe as an option in the > CYGWIN environment variable > (CYGWIN=3Dnfs_emulate_dev_special_files_as_symlink ?) One problem I see is how we can set machine-wide defaults, as the CYGWIN variable is only inherited from process to process, and /usr/bin/env - myprog will start myprog with an empty environment. So if there is no way to set machine-wide defaults, I would prefer to have the nfs_emulate_dev_special_files_as_symlink enabled by default. Thanks, Martin