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.