From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <b79747af76a853d89d5f881c07039fa5@quanstro.net>
References: <dd6fe68a0908101029k6f21e1bco967b143eaba4cad4@mail.gmail.com>
	 <b79747af76a853d89d5f881c07039fa5@quanstro.net>
Date: Mon, 10 Aug 2009 11:50:00 -0700
Message-ID: <dd6fe68a0908101150i52b92319y4c4acd287ea065f9@mail.gmail.com>
Subject: Re: [9fans] bind vs. 9660srv
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 40fd39b4-ead5-11e9-9d60-3106f5b1d025

On Mon, Aug 10, 2009 at 11:27 AM, erik quanstrom<quanstro@quanstro.net> wrote:
>> but should say (untested)
>
> s/un(tested)/\1
>
>> No one noticed before because most 9P2000 servers
>> assume they are being used correctly and implement
>> a simpler check: if offset == 0, seek to beginning,
>> otherwise continue where the last read left off.
>
> ken fs does so i'm still a bit puzzled.

Not the code I'm looking at
(/sys/src/cmd/cwfs/9p2.c)

	start += n;
	if(start < offset)
		continue;
	if(count < n){
		putbuf(p1);
		goto out1;
	}

There's no check that you get
to start == offset before copying data in.
So if you passed in an offset that was
off by a few bytes, it would get rounded
to a real directory entry boundary.

Russ