mmurphy@convex.com (Michael Murphy) (03/15/90)
I'm looking for a convenient way to determine the accessibility of a given file on a PC-NFS drive. I'd like to do this without operator intervention and with minimum timeout. Currently, when the connection to the server is down, the all too familiar message appears: Not ready reading drive X Abort, Retry, Fail? Responding 'f' causes my call to access() to report EACCES. OK fine. But what if I don't want to be there to type the 'f'? Can anybody help me out? Here's our system: PC-NFS 3.0.1 DOS 4.01 Turbo C 2.0 386 PC EtherLink 3C501 DEVICE=C:\NFS\PCNFS.SYS /m /i0 /b1 /r4 Thanks, -Mike M PS: Calls to fopen(), fprintf(), etc. behave similarly.
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (03/15/90)
Quoth mmurphy@convex.com (Michael Murphy) (in <100581@convex.convex.com>): #I'm looking for a convenient way to determine the accessibility of a #given file on a PC-NFS drive. I'd like to do this without operator #intervention and with minimum timeout. Currently, when the connection #to the server is down, the all too familiar message appears: # # Not ready reading drive X # Abort, Retry, Fail? # #Responding 'f' causes my call to access() to report EACCES. OK fine. #But what if I don't want to be there to type the 'f'? This is actually a DOS question, not a PC-NFS question. In essence, PC-NFS treats the network drive not ready condition as though the drive were a floppy and you'd forgotten to insert a diskette or close the latch... Many DOS applications - Lotus 1-2-3 for example - handle these errors internally, and there's no reason your application shouldn't as well. The key to doing this is the DOS 24H Critical Error Handler. Check out your DOS Technical Reference (in the IBM DOS 4.00 version it's page A-3) or any good down'n'dirty DOS programmer's guide. Basically, your application should take over INT24H; when a critical error occurs your handler will be called. You can then choose to ignore (AARGH! horrible option), retry, or fail the system call, or to terminate the program through INT22H. What I usually do is to store the error status in a global variable, and then FAIL the call; my mainline code can then check the global status variable. Be careful: if you are using a high-level language (C is high-level? Well...) the DOS call may not be what you expect! For example, in Microsoft C if you code an open() the first thing the C runtime library will do is issue a FindFirst for the file - NOT an Open. Note that I'm cross-posting this reply to alt.msdos.programmer. Other gurus there may have some good tips. Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) ------------------- Todays .signature has been cancelled due to inclement weather.