From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 1C90B3858D38; Fri, 8 Sep 2023 20:31:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C90B3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1694205083; bh=bviq2PdH3vnt21no0ITz/5MCGu3x7hww+Wpbiijh4E8=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=CVVKb42Ot+EiHeCqp1kIY7BVHPU8lAMwL69Zx4xllwJlKgfFvAZOYOc0XXL9gcx9D iYCuFvipEavzpFExbj0pjeXlNyuz1kmWTd6Rgc9C0qFaTe7DGyBWxhBrakh4ko0RVl cJcHnVrDbDqEmMNFuFCqXidP6/JN4QY0oS21ePxA= Received: by calimero.vinschen.de (Postfix, from userid 500) id 291B2A8086F; Fri, 8 Sep 2023 22:31:21 +0200 (CEST) Date: Fri, 8 Sep 2023 22:31:21 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: NFS mkfifo support in cygwin 3.5.0 Re: [ANNOUNCEMENT] cygwin 3.4.9-1 Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: On Sep 8 12:59, Corinna Vinschen via Cygwin wrote: > On Sep 8 06:48, Cedric Blancher via Cygwin wrote: > > So chmod() for a FIFO inode on NFS fails. Tested with MSFT NFSv3 and > > new builds of the NFSv4.1 ms-nfs41-client filesystems. > > Did you actually test this with 3.4.8? It never worked on NFS. > > Just to be clear, the above creates a Cygwin FIFO. The situation > is different with native FIFOs, created on the host. With those, > chmod worked before because native FIFOs were handled like normal files, > except in stat(2). Now that they are handled as FIFOs, the mechanism > to change the file mode doesn't work anymore, because it depends on > FIFOs being WIndows shortcuts. > > I will look into that at one point, but it's not a regression. For the records: Fixing this for native FIFOs is relatively easy. Fixing this for Cygwin emulated FIFOs is rightout impossible ATM: Cygwin FIFOs are symlinks with special content, basically containing device major, device minor and mode bits. Overwriting the mode via chmod(2) requires to change the symlink target, an operation which isn't supported for real symlinks on NFS-mounted filesystems. Consequentially, the FILE_OVERWRITE_IF creation mode doesn't work when trying to create a symlink. It always fails with STATUS_OBJECT_PATH_SYNTAX_BAD. The next idea coming to mind is to unlink and recreate the symlink (albeit not an atomic operation). This works if you call, e. g., chmod(1). Unfortunately this does *not* work if there's an open handle to the file. This occurs, for instance, in mkfifo(1) when using the -m option. It calls mkfifo(3) with the correct mode bits, and then, if that worked, and the -m option has been specified, it calls chmod(2) on the FIFO to set the same mode again. It does so while it opened the symlink with the O_PATH flag. I don't know why it does this, but albeit it looks like double work, the operation itself is allowed and should work. What happens in this case is this: As soon as chmod(2) got called, the first NtCreateFile trying to create the symlink fails with STATUS_OBJECT_NAME_COLLISION. So just check for this status code and then call unlink on the FIFO symlink. Given the symlink is in use, the unlink operation renames the FIFO to some temporary filename (that's builtin functionality of MSFT NFSv3). Theoretically the original FIFO name is now free to be reused for the FIFO symlink, but the next NtCreateFile call trying to create the symlink still fails with STATUS_OBJECT_NAME_COLLISION. Rinse and repeat. So it's still a bad idea to use FIFOs on NFS. I'll be offline for some time now for personal reasons, but if somebody has an idea how to fix this *and* understands Cygwin's inner workings, *and* can come up with a patch, feel free to send it to the cygwin-patches mailing list. Other than that, no idle musings, please. It just distracts from finding a working solution. Corinna