Xref: utzoo comp.unix.ultrix:6293 comp.protocols.nfs:1805
Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!ox.com!ox.com!emv
From: emv@ox.com (Ed Vielmetti)
Newsgroups: comp.unix.ultrix,comp.protocols.nfs
Subject: suspicious behavior of lseek() on NFS files
Message-ID: <EMV.91Feb20172904@poe.aa.ox.com>
Date: 20 Feb 91 22:29:04 GMT
Sender: usenet@ox.com (Usenet News Administrator)
Organization: OTA Limited Partnership, Ann Arbor MI.
Lines: 39


There's a way to determinine the current position and size of a
file that goes like this:

	curpos = lseek(fd, 0, SEEK_CUR);
	filesize = lseek(fd, 0, SEEK_END);
	if (lseek(fd,curpos,SEEK_SET) != 0) {
	    /* complain bitterly about this and all errors */
	} ;

and you're back to where you came from.  This shouldn't have any side
effects, or should it?

What I'm seeing (Ultrix 4.1, Dec 3100) is that NFS mounted files
sometimes read back nulls at the end of a growing file when the size
is determined this way.  Almost as the the lseek(fd,0,SEEK_END) was
zero-filling some cache somewhere with the wrong thing.  Note that on
"real" unix filesystems this works just fine (45 mb/day read this way).

A possible solution is to run it something like this (not tested)
	
	curpos = lseek(fd, 0, SEEK_CUR);
	if (fstat(fd, stbuf) == 0) {
	    filesize = stbuf.st_size;
	} else {
	    /* complain bitterly about this and all errors */
	} ;

I'd be interested in knowing what exactly goes over the wire for an
NFS fstat() call as opposed to the lseek() call; questions of
efficiency show up since this is going to be happening quite a few
times a minute.

--Ed

Edward Vielmetti
emv@ox.com

(this has been called into Ultrix support, #A 910 220-2454)