Date: Thu, 25 Jan 96 12:59:51 +0900 From: Mihoko Tanaka <m_tanaka@pa.yokogawa.co.jp> To: terry@lambert.org Cc: freebsd-hackers@freebsd.org Subject: Re: NFS trouble ? Message-ID: <9601250359.AA05302@cabbage.pa.yokogawa.co.jp> In-Reply-To: Terry Lambert's message of Tue, 23 Jan 1996 10:51:12 -0700 (MST) <199601231751.KAA17851@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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
<m_tanaka@pa.yokogawa.co.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9601250359.AA05302>