> On Aug 24, 2016, at 10:40, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>
> On Wed, Aug 24, 2016 at 02:26:21PM +0000, Trond Myklebust wrote:
>>
>>> On Aug 24, 2016, at 10:20, <bfields@xxxxxxxxxxxx> wrote:
>>> I may be misunderstanding what the client's doing. If it's doing
>>> something like this:
>>>
>>> - return first hundred entries to user
>>> - throw out cache, restart readdir with cookie 0.
>>> - skip first hundred entries, return entries 101-200 to user.
>>
>> No. If the client has a cached cookie acting as the cursor, then we look for that cookie in the new stream. If we don’t find that cookie, then we do another readdir where that cookie acts as an argument, and use that to figure out where the stream now continues.
>
> Got it, thanks, so the struct file caches the real server side cookie
> even after you throw out the cached entries? OK, I guess I need to make
> another attempt at understanding the actual code, apologies.
>
> (Doesn't that mean that in the case your last position was a deleted
> file, you're probably going to have to read the entire directory to find
> out the cookie's not there? It seems so much more painful than starting
> off with the last cookie.)
How do you cache the results of such a readdir? You'll have no reference point to figure out where you are in the stream.
Also, how do you convert that cookie into an offset that telldir() can use?
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
