From owner-freebsd-hackers Tue Jan 23 10:00:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA06349 for hackers-outgoing; Tue, 23 Jan 1996 10:00:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA06341 for ; Tue, 23 Jan 1996 10:00:49 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA17851; Tue, 23 Jan 1996 10:51:12 -0700 From: Terry Lambert Message-Id: <199601231751.KAA17851@phaeton.artisoft.com> Subject: Re: NFS trouble ? To: m_tanaka@pa.yokogawa.co.jp (Mihoko Tanaka) Date: Tue, 23 Jan 1996 10:51:12 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <9601231404.AA28044@cabbage.pa.yokogawa.co.jp> from "Mihoko Tanaka" at Jan 23, 96 11:04:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk > Hello All, > > My friend is developping a program which seek a file and read it. > Her program seeks a file with a wrong offset (i.e the offset size is larger > than the file size). It occurs panic. > > When a file is on a local disk, nothing happens. > But when a file is on NFS, it occurs panic everytime. Does it panic the NFS client or the NFS server? > off_t lseek(int fd, off_t offset, int whence) > > off_t is defined in /usr/include/sys/types.h : > typedef long long off_t > > then > off_t offset = 0x90000000 > 0 I am suspiscious of > 31 bit offset values over NFS. I suspect that there would be problems, since I believe the protocol limit is 32 bits with one bit for the sign bit for the return of error codes. I believe this is your problem. > I guess that lseek should return a error (EINVAL) when 'offset' is > larger then the file size . > What do you think ? No. A seek to a valid location not in the file is perfectly legal, even when followed by a read or a write (the first should return an EOF error, the second should cause the file to be sparse). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.