Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!eastapps!hinode!geoff
From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: When NFS fails
Message-ID: <5844@eastapps.East.Sun.COM>
Date: 30 Apr 91 20:38:35 GMT
References: <1991Apr30.165109.23950@jadpc.cts.com>
Sender: news@East.Sun.COM
Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Organization: Sun Microsystems PC-NFS Engineering
Lines: 26

Quoth jdeitch@jadpc.cts.com (Jim Deitch) (in <1991Apr30.165109.23950@jadpc.cts.com>):
#Does anyone have sample source for a program that checks to see if an
#NFS mounted drive is valid?
#
#What I need is a way to check to make sure that the server is alive
#and that I can read/write the drive from PC-NFS.  I am writing an
#automated system that will be reading/writing an NFS mounted drive
#from about 2000 miles away.  If the NFS mounted drive is not valid for
#any reason I can't have the machine sit there saying Abort, Retry or
#Ignore.

The way to think of this is to pretend the NFS drive is a diskette: the
problem is analogous to determining whether or not there's a diskette in
the drive before you access it. The solution for both is to write
an INT24H critical error handler. The DOS Tech Ref defines how you
should do this: what the stack frame looks like, and so forth. To avoid
the user "Abort, Retry, Fail" dialogue, your handler can simply set AL
to the desired value and IRET back to PC-NFS, which will take the
appropriate action. None of this is PC-NFS specific. 

Geoff

-- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)   --
------------------------------------------------------------------------------
--     Sun Microsystems PC Distributed Systems ...                          --
--            ... soon to be a part of SunTech (stay tuned for details)     --