Date: Fri, 6 Oct 2000 13:40:17 -0500 From: Dan Nelson <dnelson@emsphone.com> To: Paul Herman <pherman@frenchfries.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: fifos over NFS Message-ID: <20001006134017.A13617@dan.emsphone.com> In-Reply-To: <Pine.BSF.4.21.0010062021320.281-100000@bagabeedaboo.security.at12.de>; from "Paul Herman" on Fri Oct 6 20:29:12 GMT 2000 References: <20001006102356.A29878@dan.emsphone.com> <Pine.BSF.4.21.0010062021320.281-100000@bagabeedaboo.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Oct 06), Paul Herman said: > On Fri, 6 Oct 2000, Dan Nelson wrote: > > I think that's expected behaviour. Fifos should be usable on NFS > > mounts, but an active fifo is only usable for processes running on > > the same machine. > > That's cool, seems reasonable. > > BTW, the hanging behavior I was seeing didn't have anything to do > with NFS -- it was the same if I tried to write to a local fifo with > nothing listening on the other side (no NFS). That's how fifos work; you're blocking on the open, not the write. Open with O_NONBLOCK if you want to the call to fail if there's no-one at the other end. > So I guess opening a fifo over NFS doesn't even reach nfs_open() in > sys/nfs/nfs_vnops.c which would return an EACCES on a VFIFO. OK, I > think I'm satisfied. Thanks! That's probably the case, if you're looking at the server code. If a client ever actually tried to open a fifo over NFS (say they're running an OS that doesn't know about them, like Windows), it'll return the error. My guess is that on the Unix client end, the open request is handled by the kernel and nothing is ever sent to the remote NFS server (just like opening a devicenode). -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001006134017.A13617>