Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!turnkey!jackv From: jackv@turnkey.tcc.com (Jack F. Vogel) Newsgroups: comp.unix.aix Subject: Re: Control NFS exported filesystems Message-ID: <1991Jun20.112235.8055@turnkey.tcc.com> Date: 20 Jun 91 11:22:35 GMT References: <1991Jun19.172354.9964@turnkey.tcc.com> <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun19.154830.17276@uai.com> <1991Jun19.162331.25505@bellcore.bellcore.com> <8623@awdprime.UUCP> Reply-To: jackv@turnkey.TCC.COM (Jack F. Vogel) Organization: Turnkey Computer Consultants, Westchester, CA Lines: 34 In article <8623@awdprime.UUCP> marc@aixwiz.austin.ibm.com writes: >In article <1991Jun19.172354.9964@turnkey.tcc.com>, >jackv@turnkey.tcc.com (Jack F. Vogel) writes: [ stuff about using the 'hard' nfs mount option not preventing data loss] |Mounting the file system hard will not prevent the problem. An |application will |not "see" the error until a fsync or close is done on the file. Probably what |is happening with vi is that it is not checking the return from close. I can't |ever remember seeing someone check the return from a close with all the |code that |I have looked at. Right, its not just an issue of user-written applications not doing this, its that every application "command" in the system, like vi, don't do this. Marc, you and I both know where this issue is coming from (like a certain customer complaint :-) and this is BOGUS. The user is free to write code to check the return from close should he like, but rewriting vi ?!? NO, the right option as far as I am concerned is what was done in 4.3reno, provide a synchronous option to mount!! >As an aside does anyone out there check the return from close in their >programs? We could probably generate a month-long thread of arguments in comp.unix.wizards on the appropriateness of this :-} :-}! Disclaimer: I hack the kernel, I don't speak for the company. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM