X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06DB1385770F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1692976527; bh=GjrfY/xpxpeCZsxgbdSSEsk9JJlsg/duGcJ/OVy05RE=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=E5qqbiirMyq0Zkb+gGvx9dyV4w3wFWm1yFp8VrUTWE5lJmV1YJmkTVxxgjqP3GZF+ nbpKA/lYLLOKyrjXXPGnlF0BHkXq9RKVtK/N18bOmJ3hnzHDWziqSw5R/UUyAfsw9e dLkVqDJ2Eko6XmOxVPnI3fgUXp6zilpDh39xbsr4= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00AD73858C53 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692976509; x=1693581309; 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=+KuPulrR/kDvxzudeIjmCz1OxFpVUhvhxA1attM/VxA=; b=PZkSHhuKuuAs5oFRDtkSdxrO67Dw6EuIU2/Dd4hrVAiY8+BKNZqt1HjvoDVj5YIRjm fyxtX7dzAYY14/NeWnM+uZePrUbyeNFKoYH4H3LtIiivK9Fjz9GrZNeNX8Tu5wAjo2NU QPU6xqynhvEBldBhXV0JC8vhJfU4Vegm4KWmMYf5oyFWUMxzJ/MLcptAR7tSNYGKa6dM 8OroKE3F+LqXeeTbI1cSND81DRUGu15fD3sD8vzcxqAQS4GU/JrJQHQFVAa1fD1pnOV4 Cw2FkrKo1BBWh8S0wDzVN31JouuvUBj6AqCJxxKCAN8PBeVFcaDLIUyubD0D8rY/hR6n Pmlw== X-Gm-Message-State: AOJu0Yy89+h14bsMaLThxZgEmpg9Eo0x00dp3LZviXMs5Rx7ZtixGalA WGFeZ/s+RqYbWE66/D17jCcKrsPnMeveOAilvC/kkaNEY30= X-Google-Smtp-Source: AGHT+IExtuXkd3et8rcWydhBusJGQpuMBj3xUQVCz94jKlzz1P7nxpo8GTHwK99kKP+otPRO+o4MCOwvJWvtBMcY53E= X-Received: by 2002:a5e:d90a:0:b0:783:49ec:8115 with SMTP id n10-20020a5ed90a000000b0078349ec8115mr9445380iop.5.1692976508906; Fri, 25 Aug 2023 08:15:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 25 Aug 2023 17:14:42 +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 AT cygwin DOT com Cc: Corinna Vinschen 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 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: Roland Mainz via Cygwin Reply-To: Roland Mainz Content-Type: text/plain; charset="utf-8" Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 37PFFRde007978 On Fri, Aug 25, 2023 at 2:18 PM 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=nfs_emulate_dev_special_files_as_symlink 3. (CITI) ms-nfsv41-client: adds a private API to do a |mknod()| 4. Cygwin: Implements the new API added in [3] as *prototype*, so |mknod()| will properly work in a portable manner 5. We ask Microsoft to review the private API created in [3], and ask them to implement it for the Microsoft NFSv3 client too (because we have a precedent with [4]!) Optional: 6. Cygwin: Like [1] add "afs_emulate_dev_special_files_as_symlink" to do the same for AFS 7. Cygwin: Like [2] |mkfifo()| should fail on AFS, unless [6] ... Issues: - [6] and [7] should be decided by the owner of the Microsoft AFS filesystem driver. - Should the new Windows NFS mknod-API be only available for accounts with administrator rights/permissions ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland DOT mainz AT nrubsig DOT org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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