eef4aaba6b
If you perform this request on a directory with exactly 50 files (plus '.' and '..' which brings the total to 52 objects), the first reply for the SMB server completely satisfies the query (server side is Windows 2000 Professional). The smbfs client then performs a TRANS2_FIND_NEXT2 using the last file name as the resume key. The response returns a SearchCount of zero (ctx->f_ecnt == 0) and an EndOfSearch code of zero. Any attempt to get more entries with calls to TRANS2_FIND_NEXT2 result in Badfid (bad file descriptor). I suspect the return of SearchCount of zero means that end-of-search has been reached and the Sid is now closed. The solution is to set "SMB_RDD_EOF | SMB_RDD_NOCLOSE" after getting back a zero SearchCount, I've tested this in the field on a quite a few systems, aggressively accessing Windows shares over smbfs and it appears flawless. I was initially concerned about the possibility of resource exhaustion on the Windows server. I was afraid by not officially closing the search, it would leave a resource hung-up and over time, exhaust some sort of "open search table" limit. I've since convinced myself this is NOT the case. Windows needs to be able to handle clients that come and go over time. If the search is not closed, Windows will close it if it finds it needs more resources. I've testing this on directory searches descending into 10's of thousands of folders, with 100's of thousands of files. |
||
|---|---|---|
| .. | ||
| adosfs | ||
| cd9660 | ||
| filecorefs | ||
| msdosfs | ||
| ntfs | ||
| ptyfs | ||
| smbfs | ||
| sysvbfs | ||
| tmpfs | ||
| udf | ||
| union | ||
| Makefile | ||
| unicode.h | ||