From owner-freebsd-hackers Wed Jan 24 20:00:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA23450 for hackers-outgoing; Wed, 24 Jan 1996 20:00:19 -0800 (PST) Received: from yokogawa.co.jp (yhqfm.yokogawa.co.jp [202.33.29.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA23185 for ; Wed, 24 Jan 1996 19:59:15 -0800 (PST) Received: from sjc.yokogawa.co.jp ([133.140.4.100]) by yokogawa.co.jp (8.6.9+2.4Wb3/3.3Wb4-firewall:08/09/94) with SMTP id MAA25396; Thu, 25 Jan 1996 12:58:51 +0900 Received: from leia.pa.yokogawa.co.jp by sjc.yokogawa.co.jp (4.1/6.4J.6-YOKOGAWA-R/GW) id AA22232; Thu, 25 Jan 96 12:58:50 JST Received: from cabbage by leia.pa.yokogawa.co.jp (16.8/6.4J.6-YOKOGAWA/pa) id AA03498; Thu, 25 Jan 96 12:58:50 +0900 Received: by cabbage.pa.yokogawa.co.jp (16.6/3.3Wb) id AA05302; Thu, 25 Jan 96 12:59:51 +0900 Date: Thu, 25 Jan 96 12:59:51 +0900 From: Mihoko Tanaka Message-Id: <9601250359.AA05302@cabbage.pa.yokogawa.co.jp> To: terry@lambert.org Cc: freebsd-hackers@freebsd.org In-Reply-To: Terry Lambert's message of Tue, 23 Jan 1996 10:51:12 -0700 (MST) <199601231751.KAA17851@phaeton.artisoft.com> Subject: Re: NFS trouble ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@freebsd.org Precedence: bulk >>> 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? The NFS client does. >>> 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. Yes. I think so. But I guess that the kernel must not panic even if a user program do anything. >>> 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). You are right. I'm sorry I have taken it wrong. -- Mihoko Tanaka