[PATCH] RFC: vfs cachedir

[Aurélien Aptel]

Hi,

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.

On a NFS mount (and I suspect on other non-trivial fs), the DIR handle
can be updated after being opened. That means that setting the offset to
the supposedly same value might end up skipping files.

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.

So I've written a small VFS (attached) that just caches a DIR handle
when it's opened. It reads all the directory entries in a structure that
is used in place of the DIR handle (which is closed as soon as we read
all the entries). It makes a "snapshot" of the directory, so to
speak. The rewind operation just resets the internal cursor and does not
read the directory again.

This VFS seems to solve the issue in this specific scenario. But I'm
sure it could fail in others (which ones?). Would you let customers use
this VFS? Should it be merged?

1: http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir.html

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p
Type: text/x-patch
Size: 8545 bytes
Desc: cachedir vfs
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170419/fa3356bf/p.bin>