vjs@rhyolite.SGI.COM (Vernon Schryver) (11/07/87)
In article <8711042328.aa12082@SMOKE.BRL.ARPA>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes:
- Some programs (e.g. good old Kermit) do wild card expansions in their
- code. Due to the lack of existing routines the do it by their own (see
- the "expand" modules in Kermit). They use (due to the lack of BSD like
- opendir/closedir routines) open and read statement to access the
- directory files (which are told to be "normal" files with the exeption
- that you cannot write them). Now the problem: with the EFS directories
- everything works fine, with the NFS directories everything I get from
- read seems to be junk. Result: I cannot use Kermit to do wildcard
- get/send's on the NFS disks. Is this a problem/bug or feature? Is this
- known? Will this be fixed in the next (3.6) release?
In summary, this is a feature, not a bug, of NFS.
In detail:
It might be called a bug in how Kermit was compiled for your machine.
If you got it from SGI, you ought to send a bug report to the hotline.
The familiar BSD opendir(3)/closedir(3) routines are available on IRIS's.
Both BSD and SV flavor opendir/closedir functions are available.
They work on EFS, NFS, and BFS file systems. To get BSD flavor,
you must use '-lbsd' and '-I/usr/include/bsd' with ld and cc.
For BSD style programing, you generally want to use '-lsun -lbsd'
and '-I/usr/include/sun -I/usr/include/bsd' to get Y.P. support.
Y.P. will not work unless you also have NFS, but linking with it
will do no harm.
In EFS, it is possible to abuse file directories with open(2) and read(2).
However, it would be wise not to count on such a 'facility.'
As is standard in NFS, you get EOF on the 1st read(2) of an NFS file
directory.
The only coming change in this area that I recall, is that we will track
the change made in the SVR3.1 SVID to the magic cookie from telldir(3).
This means that both flavors of cookie will have the same taste. :-)
Cheers,
Vernon Schryver
Silicon Graphics, Mtn.View, Ca94043
vjs@sgi.com or {decwrl,sun,adobe,pyramid,research}!sgi!vjssparks@batcomputer.tn.cornell.edu (Steve Gaarder) (11/09/87)
We, too, are having lots of trouble with NFS. We have two Iris 3020's
which are set up as clients with a Vaxstation II/GPX running Ultrix
2.0 as the server. We have the following trouble:
1. "pwd" does not work in most (but not all) NFS directories. It gives
"read error in .."
2. C-shell scripts do not work in the same directories. The error here is
"file not found". Bourne shell scripts run fine.
3. Occasionally, if there are 2 or more users running ld, the server
or one of the clients will crash.
Any and all suggestions for fixes would be greatly appreciated. Students
have managed to cope ok, but our developers now refuse to work in NFS
directories.
--
Steve Gaarder
Cornell University, 171 Hollister, Ithaca NY 14853 607-255-5389
UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!sparks
BITNET: sparks@crnlthry.BITNET ARPA: sparks@tcgould.tn.cornell.eduSML108@psuvm.psu.edu (Scott Le Grand) (07/14/90)
I have a question. I am trying to link two IRISES by NFS. If I specify a limited range of hosts in fstab, they both say "Access denied" even to the hosts specified as legal. If I remove the host limitation. One works fine, and it is running 3.3, while the other, which is running 3.2.2 rejects the other's attempt to access it... Any ideas? Scott
CMSDS@UGA.CC.UGA.EDU (David Stewart) (12/04/90)
Thanks to all who responded to my NFS configuration problem. It turned out that the reason the os didn't see NFS correctly was that the kernal had not been reconfigured. lboot took care of it. +---------------------------------------------------------------+ | David Stewart - University Computing and Networking Services | | Specialized Systems Support - (404) 542-5110 | | University of Georgia - Athens, GA | |---------------------------------------------------------------| | Internet: CMSDS@UGA.CC.UGA.EDU | Bitnet: CMSDS@UGA | | -or- STEWART%GANDAL.DNET@SERVER.UGA.EDU | +---------------------------------------------------------------+
drw900@anusf.anu.oz.au ("Drew R Whitehouse") (12/10/90)
I've got a weird thing happening with NFS mounted file systems. I'm mounting a file system from a Sun 4/330 SunOS4.1 onto a 4D210/VGX 3.3.1. Everything works fine except when I write a file onto the nfs f.s., it's dated an hour behind...The time is right on the sun and the sg, writing a file on the sg's own disks works as expected. It used to work...I don't know exactly when it stopped. Maybe it's something to do with NFS ?? daylight saving ?? Any suggestions welcome.... (One thing I've noticed - touch updates the date correctly, things like editors and compilers (.c -> .o) don't.) Drew. -- /*---------------------------------------------------------------------------*/ /* Drew Whitehouse, E-mail: drw900@anusf.anu.edu.au */ /* Visualization Programmer, (NOTE: recent change, no more csc2 ) */ /* Australian National University, Phone : (06) 2495985 */ /* Supercomputer Facility. Fax : (06) 2473425 */ /* GPO Box 4, Canberra ACT Australia 2601. */ /*---------------------------------------------------------------------------*/
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (12/11/90)
In article <1990Dec10.163637@anusf.anu.oz.au>, drw900@anusf.anu.oz.au ("Drew R Whitehouse") writes: > > I've got a weird thing happening with NFS mounted file > systems. I'm mounting a file system from a Sun 4/330 SunOS4.1 onto a > 4D210/VGX 3.3.1. Everything works fine except when I write a file onto > the nfs f.s., it's dated an hour behind...The time is right on the sun > and the sg, writing a file on the sg's own disks works as expected. It > used to work...I don't know exactly when it stopped. Maybe it's > something to do with NFS ?? daylight saving ?? Any suggestions > welcome.... > > (One thing I've noticed - touch updates the date correctly, > things like editors and compilers (.c -> .o) don't.) It would probably be effective to follow your daylight savings idea. IRIX and SunOS keep time in GMT, and convert to human readable form. If the two systems had different notions of the timezone (e.g. differing ideas of whether daylight savings is in effect), one would see the effects you report. The NFS server is responsible for chosing mtime in normal writes and creates. It seems right that setattrib() passes all of the times over the wire. Thus, touch might have a different effect. On an IRIS or other SV system, the TZ env. variable controls the decoding of the kernel's idea of time. `(unsetenv TZ; date)` will display the unvarnished date and time. Something similar might be available on the Sun. On an IRIS, try `man timezone`. Vernon Schryver, vjs@sgi.com