Re: Stateless SFTP server and READDIR race condition.

[Nicolas Williams <Nicolas.Williams%Sun.COM@localhost>]

On Tue, Apr 18, 2006 at 02:14:18PM -0400, der Mouse wrote:
> > I guess the question becomes, why would one ever want to implement a
> > stateless server?  I don't know.
> 
> It greatly simiplifies many aspects of crash recovery.

Until you realize that you want locking, and better caching semantics,
and...   And you realize that none of those things can be done in an
entirely stateless manner, that you need to figure out how to deal with
client and server crashes as well as network partitions.

> >>> Also, there is a potential race condition when there are multiple
> >>> READDIR calls.
> >> Could you detail this?  I don't see any race condition unless there
> >> are directory-modifying calls involved.
> > 1. SFTP OPENDIR causes an opendir() on the server.
> > 2. 1st SFTP READDIR causes 100 call to readdir().
> > 3. Third party modifies directory on server in some arbitrary way.
> > 4. 2nd SFTP READDIR causes at most 100 additional calls to readdir().
> > Entries could be missed.
> 
> True.  But the same applies to any other way of reading a directory on
> most systems, even including local ls or moral equivalent.

I suspect that what the above quoted text was getting at is some sort of
directory change notification system; go check out the NFSv4 WG list
archives for why this is not trivial.  BTW, notifications == more state.

Nico
--