[PATCH] RFC: vfs cachedir

Jeremy Allison jra at samba.org
Wed Apr 19 17:14:29 UTC 2017


On Wed, Apr 19, 2017 at 03:49:24PM +0200, Aurélien Aptel via samba-technical wrote:
> 
> That means that:
> 
> - if you take the current offset with telldir
> - delete files in the dir
> - and seek to that same offset with seekdir
> 
> the same offset might point to a different file.
> 
> 	  DIR*
>      off.     
> 	0 file a
>        10 file b
>    ->  20 file c   
>        30 file d
> 
> telldir(dir) == 20
> ...something somewhere delete file a...
> seekdir(dir, 20)
> 
> 	  DIR*
>      off.   	 
> 	0 file b
>        10 file c      
>    ->  20 file d
> 
> next readdir() will return file d instead of file c.
> 
> Here is what POSIX[1] says about readdir():
> 
> > If a file is removed from or added to the directory after the most
> > recent call to opendir() or rewinddir(), whether a subsequent call to
> > readdir() returns an entry for that file is unspecified.

Oh sorry, missed this. I assumed that you were
having problems on NFS with no one else writing
or deleting in the directory.

Yes of course if someone is writing into the directory
then all bets are off w.r.t. getting coherence out of
readdir etc.

This is a race condition you simply can't win.

Even if you opendir/readdir..../closedir
there's no guarentee that someone didn't
delete one of the names you read with
readdir.

The only way around this is directory
leases, and break the lease to let the
client know someone else is writing into
the directory.

But even with that there's still no way to fix a race
condition like this - all you're doing is
exposing a frozen snapshot that can be
out of date from the moment you return it.



More information about the samba-technical mailing list