[PATCH] RFC: vfs cachedir

[Jim McDonough]

On 04/19/2017 01:14 PM, Jeremy Allison via samba-technical wrote:
> 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.
In this case, windows is racing itself.  "del *" or "move *" triggers
it.  As each chunk is returned, all those files are deleted.  _then_ the
search is resumed, but we're lost.
> 
> 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.
> 
Yep, but frankly we're simply lucky that "del *" works on a local fs.
Apparently ext<n>, btrfs, xfs, etc. are just not updating the directory
from the viewpoint of our open handle as frequently.  Windows cmd.exe
clearly expects the behavior of a frozen snapshot.