Mail Archives: cygwin/2023/09/08/16:31:58
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
--
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
- Raw text -