On Tue, 19 Oct 1999, Urban Widmark wrote:
>
> Has anyone else seen these?
>
> smb_proc_readdir_long: name=, entries=117, rcls=1, err=123
> smb_refill_dircache: readdir failed, result=-2
Apparently not ... I switched to a clean kernel, and tried some more. Here
is what I found.
It fails on a clean 2.2.12, so my nls thing is not the culprit.
I looked at some debug output from smbclient, and from that I guessed that
smbclient uses 40 as a limit for the # of filenames.
In fs/smbfs/proc.c:smb_proc_readdir_long there is a limit on the number of
filenames to return in one go, max_matches. It is set to 512.
I changed it to 40, that worked. 80, 110, worked, 120 failed, 115, 117,
118, 119, worked, 120 again now that worked ... but not 130, and not 120
again (I probably made an error before).
I'm thinking this has something to do with the long filenames, possibly a
buffer/packet size thing. In a different directory with 5795 files with
much shorter names (we are still in smb_proc_readdir_long though) the
default value works. The server does not return more than ~160 entries per
call (possibly limited by something else).
in filename length: 170 * short < 120 * long
Are there any known server issues, and that is why 40 is used by
smbclient?
(if it actually uses 40, I could have misread that output completely)
I'm too tired to think more about this now. Maybe if I sleep on it someone
else will solve it for me ... :)
/Urban