[PATCH] RFC: vfs cachedir

[vl at samba.org]

On Wed, Apr 19, 2017 at 03:49:24PM +0200, Aurélien Aptel via samba-technical wrote:
> A customer is re-exporting a NFS mount through a samba share and is
> having some strange issues e.g. when mounting the share on a Window 7
> system and running "del /q *" in it, only half the file are deleted.
> 
> I know re-exporting NFS mounts is not recommended but I've tried to
> debug this anyway.
> 
> As it turns out the reason why it fails is because smbd assumes that
> directory offsets given by telldir() can be reused and set again by
> seekdir().
> 
> More specifically when doing FIND_FIRST/FIND_NEXT requests against a
> directory with a lot of files, several FIND_NEXT requests have to be
> sent to get the full listing, and each one provides an offset into the
> results. For SMB2+ code, samba "fakes" smb1 requests out of the smb2
> ones and the same code is used.

Your module looks interesting! :-)

Brainstorming....

Dumb question (I haven't looked at that code for ages): Why do we play
telldir/seekdir tricks at all? Why don't we just opendir/readdir/closedir
in the highlevel code?

If we inevitably have to do the seekdir/telldir (Jeremy?? :-), shouldn't
we put your code into core Samba and do the caching always?

And -- would it help if we didn't do the telldir/seekdir thingy? Also,
isn't readdir() inherently racy? Caching the whole thing will solve
the race against ourselves (which is very likely the 99.9% solution),
but will it also help against others modifying the directory concurrently?

Volker