Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Re: Remote File Sharing (RFS) - SVR3 Message-ID: <5487@brl-smoke.ARPA> Date: Wed, 7-Jan-87 11:09:38 EST Article-I.D.: brl-smok.5487 Posted: Wed Jan 7 11:09:38 1987 Date-Received: Wed, 7-Jan-87 23:03:35 EST References: <261@unixprt.UUCP> <371@oblio.UUCP> <10938@sun.uucp> <1583@ulysses.homer.nj.att.com> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 11 Keywords: RFS, SVR3 Xref: mnetor comp.unix.wizards:520 comp.unix.questions:560 I think Guy's point was that the CONNECTION (e.g. "file") is broken by the link going down, and even though RFS re-advertises systems when they come back up, it is too late for the particular connection, since the first I/O operation after the link outage returned an I/O error rather than blocking until the link came back up. Which of the two ways of dealing with this is better depends on what one is trying to do. Personally I prefer the immediate I/O error in most situations. A broken link seems to me to be much the same as a disk drive going off-line.