Bug 3526 - Missing SMB_FIND_ID_{FULL,BOTH}_DIRECTORY_INFO handling
Summary: Missing SMB_FIND_ID_{FULL,BOTH}_DIRECTORY_INFO handling
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.9
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2006-02-19 14:55 UTC by Corinna Vinschen
Modified: 2006-02-19 14:58 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Corinna Vinschen 2006-02-19 14:55:00 UTC
After reimplementing readdir() in Cygwin using the
NtQueryDirectoryFile(FileIdBothDirectoryInformation) call, we encountered the
following weird behaviour when accessing remote Samba shares:  In directories
with a lot of entries (> 128), we only ever got the first 128 directory
entries, never any more.  The next NtQueryDirectoryFile call after getting
the first 128 directory entries returns STATUS_INVALID_LEVEL. If we switch to
using the FileBothDirectoryInformation after getting this error, that call
returns STATUS_NO_MORE_FILES.  This does not happen when using the
FileBothDirectoryInformation level right from the start.

I *think* I found the cause of the problem.  In source/smbd/trans2.c,
there are the two functions call_trans2findfirst and call_trans2findnext.
The call_trans2findfirst function knows about SMB_FIND_ID_FULL_DIRECTORY_INFO
and SMB_FIND_ID_BOTH_DIRECTORY_INFO, and handles them gracefully.  The
call_trans2findnext function does not know these two values and returns
NT_STATUS_INVALID_LEVEL in line 1936.  If I didn't miss anything, this problem
should be solved by adding the SMB_FIND_ID_FULL_DIRECTORY_INFO and
SMB_FIND_ID_BOTH_DIRECTORY_INFO values to the allowed values in the
affected switch statement.

Comment 1 Jeremy Allison 2006-02-19 14:58:51 UTC
Perfect analysis - thanks !
Will be fixed in 3.0.21c.