[PVFS2-internal] Re: [PVFS2-CVS] token adjustment?

[Rob Ross]

On Mon, 9 Feb 2004 neillm at mcs.anl.gov wrote:

> On Mon, Feb 09, 2004 at 04:07:16PM -0600, Rob Ross wrote:
> > Those tokens were supposed to be opaque values, so we should not be doing 
> > math on them on the client side!
> 
> Yep, well we have a problem.  When a 'rm -rf' is issued, a readdir is
> issued, followed by unlinks of all of those entries returned.  This
> readdir/unlink is repeated until all entries in the directory are
> removed, when finally the directory itself is removed.
> 
> We keep state between readdir calls in the VFS to get full listings.
> And that means we store the position and keep bumping it up for the
> next issued readdir.  Problem is that in the above scenario, we can't
> do that because 'opaque offset 40' will no longer be valid if there
> are only 2 remaining entries in the directory (which say originally
> had 42 entries).
> 
> > Can someone please explain how things are set up right now, so that we can 
> > discuss this some?
> 
> Done.  If there's a better solution, I'm interested, as I tried to
> consult Phil earlier to no avail.

I'm worried about the client playing with that value because it's a hack 
-- there's really no way to know for sure that the client is getting it 
right.

I think that perhaps we should return a code from PVFS_sys_readdir() that
indicates the directory has changed since the token was issued and force a
restart at the beginning of the directory?  This should be just fine for 
rm.

My concern with that plan is that someone creating files like mad in a 
directory might make it nearly impossible to read the whole thing.

Maybe the restart is only necessary when something is *removed*?

Rob