Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: getcwd() and friends. Message-ID: <1470@auspex.auspex.com> Date: 19 Apr 89 08:54:14 GMT References: <7882@june.cs.washington.edu> <10671@bloom-beacon.MIT.EDU> <7911@june.cs.washington.edu> Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 28 >The issue is not blocking temporarily while waiting for disk or network >I/O to take place. The problem is that the open system call, rather than >succeeding or reporting an error, can simply block forever. The O_NDELAY >flag prevents this under both System V and BSD. If you run NFS (which is >not part of either System V or BSD UNIX at this point), then the O_NDELAY >flag won't help you. There is some confusion here. The "block forever" stuff applies to special files and FIFOs, not to regular files; while you can open a special file or FIFO that exists on a remote machine, the file in question refers to a local object. If you do an open on a special file that exists on an NFS file system, O_NDELAY most definitely *will* get passed to the *local* driver for that special file's device, and it will act on it just as if you'd opened a special file on a local file system (in fact, the driver has no idea that the file exists on a remote machine - which, for the case of a diskless machine, is the way it should be; if I open "/dev/console" on my diskless workstation, I want *my* console, not the server's console!). The same applies for FIFOs that exist on NFS file systems. (They act as rendezvous points for local processes only.) In either case, the local software, when seeing the O_NDELAY, will honor it if the file was an NFS file, as long as it would have honored it were it a local file. That is definitely true for FIFOs, at least under SunOS, and true of tty devices, at least.