From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 4E6943858C53; Sat, 26 Aug 2023 11:28:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E6943858C53 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-x134.google.com with SMTP id 2adb3069b0e04-4fe21e7f3d1so2701671e87.3; Sat, 26 Aug 2023 04:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693049316; x=1693654116; 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=pGyf6L3AlUv0rwTnoHMUzWc6zs2deTGR2yYD6Iuy2/I=; b=nIBZJPxxdP0r7NZSYD2ptlvgwtjUB0qOSSU6AIO1d+DF09ndr8ziM/2yv9Zg/6bPzo QbpLoNyKFE6sv2GMOq9SytUM9rZs3zRxsOD4/4ZJplyUZWvOeT4sH5Kk7bpfPz6qVBrf LZsYvN5c9FLTBP8/F5NEbivHOuvYllRSSLezoyhpg1gesRTdHGt0gIndFKF7kjHqh0jx KNEx/LQZBdE3KYSLJZxdBsWfGaZR2hSdIVvBKJ6ZCLYf/uvxCKnjyCFxn2ZDk3O9W54t BFeRz5xM52sTmkWDCnGU0/dJxSXwmbD9kcUsSflR2UGVR7w6KhT2E4ZiCTJk0NxVY7dZ upZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693049316; x=1693654116; 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=pGyf6L3AlUv0rwTnoHMUzWc6zs2deTGR2yYD6Iuy2/I=; b=IlKbGpNg2xkerjXsc9dpagiJZB/IX2DnX84hF5QOg5VvBwZKtVKXY5XdMnrYz2CJ0f 138ijfopaE8gmhFvwnd9ExO8gV/FCMf3VHEV+nESHsXqJt/cnqBZZ+jQf5h94If6RN++ Xdb6tzLFv/kMlkWasYEoox97udgTUfWQobU2ildiSwLZCZbwDwVRB/y53bACiKqJRyZ6 5E/V+SMhS9xcd/TrQpOsawF2DZ8ovwZGec8anP4kAKeWNOQE6+Sow3jTmS9LKQg7vtip d8nPQPwd3kODwTjSByUEk0LKHs1eSbLCQoCSI0UGBRl2hYJY1Au/UfjvHQBQZDp3W6/S pNow== X-Gm-Message-State: AOJu0YwD7gq+pCVsV270dLresodNKMhbL4HFr51oNLoB9PZqgU9NuqG5 3Cq+2uKj2af8sNdy9n+EbJvZq9bfasuNZCQZrsJshmrZqqC2TA== X-Google-Smtp-Source: AGHT+IEZ1t9PX9XF8H9aX2uR1UpJ+Grx5ntbtakSQ3oiI+6ahT4NOHKRLkEza+zxFOWLBhWBJT4GZkundZfBa6oQeZw= X-Received: by 2002:a05:6512:130c:b0:500:9969:60bf with SMTP id x12-20020a056512130c00b00500996960bfmr8616052lfu.68.1693049315461; Sat, 26 Aug 2023 04:28:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cedric Blancher Date: Sat, 26 Aug 2023 13:27:59 +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: Roland Mainz 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 Fri, 25 Aug 2023 at 17:15, Roland Mainz via Cygwin w= rote: > > On Fri, Aug 25, 2023 at 2:18=E2=80=AFPM Corinna Vinschen via Cygwin > wrote: > > > > 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 > > I know. > > > 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... > > I think most issues have been fixed for the Microsoft NFSv3 client, > and for the CITI NFSv4.1 client (technically it's called > "ms-nfsv41-client") the situation is even better since it's > opensource, and we can fix problems even faster there. > From what I see the ms-nfsv41-client is stable enough for daily > routine usage, and I know that other institutions like DFG and CERN > use it for daily work too. The only nasty part is the damn lack of > documentation, and that there are no signed binaries, so any kernel > with UEFI/SecureBook cannot use them. > > > Anyway. How would you like to make sure that a Cygwin application > > can differ between real FIFOs and Cygwin FIFOs? > > For now I can provide a migration script, and in the medium term we > should get Microsoft to provide some kind of |mknod()| API. see below. > > > > 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. > > See below. > > > > 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. > > Looking at the ms-nfs41-client source code, there is no API for that *YET= *. > > So my plan would be like this: > 1. Cygwin: implements the proposed devnodes-as-symlink emulation code, > if the env var CYGWIN has "nfs_emulate_dev_special_files_as_symlink" > set > 2. Cygwin: By default |mkfifo()| will fail with |ENOSYS| (not |EPERM|, > as we intend to fix the issue!) on NFS filesystems, unless > CYGWIN=3Dnfs_emulate_dev_special_files_as_symlink I think the emulation should be on by default, or you break things. Ced --=20 Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur