rsync: readdir(.): Bad file descriptor (9)

[Michael B Allen]

On Tue, 8 Nov 2005 12:24:07 -0500
"Jim Carroll" <jim at carroll.com> wrote:

> Hi,
> 
> I've spent the better part of three weeks tracking into this problem. I
> hope you don't mind a post here on smbfs, but I was hoping someone might
> have some insight or ideas on where to look next.
> 
> Summary: trying to rsync folders across an smb mounted share with
> EXACTLY 50 objects (folder or files), results in the error
> 
> 	rsync: readdir(.): Bad file descriptor (9)
> 
> Details
> 
> The problem seems to be related to the number of objects in a folder.  
<snip>
> The source of the error message is /usr/src/sys/netsmb/smb_rq.c
> Line 344
> 
> if (rqp->sr_vc->vc_hflags2 & SMB_FLAGS2_ERR_STATUS) {
>     error = md_get_uint32le(mdp, &rqp->sr_error);
> } else {
>     error = md_get_uint8(mdp, &rqp->sr_errclass);
>     error = md_get_uint8(mdp, &tb);
>     error = md_get_uint16le(mdp, &rqp->sr_serror);
>     if (!error)
>         rperror = smb_maperror(rqp->sr_errclass, rqp->sr_serror);

First, this is obviously where the client just reads the error code from
the server.  So if we try to guess what is happening, the client issues
an SMB_COM_FIND_FIRST2 and possibly one or more SMB_COM_FIND_NEXT2. But
at some point either one of these commands fails with an error that gets
translated to "Bad file descriptor" which *suggests* that the search
handle was invalidated or closed (e.g. an SMB_COM_FIND_CLOSE followed
by a subsequest SMB_COM_FIND_NEXT2 on the old handle).

Because the error seems to be on the server I would definitely get a
packet capture and look at the FIND_FIRST2 parameters like the "close
on end of search flag". It could be that a bug somewhere is causing this
flag to get turned on or the server (what's the server?) is interpreted
the command in a strange way causing the search handle to close.

> What's particularly interesting, is other utilities can successfully
> recurse into the directory without any problems (example: ls, find,
> ...).  I can only seem to create the problem using rsync.

Or it could be a combination of the filename being '.' and the number of
files necessary to exercise a packet boundry code path.

This is all wild speculation of course. I know nothing of the actual
smbfs code. I just wrote a CIFS client in Java once.

Mike

PS: Don't post captures larger than ~4K to the list. If you can't figure
it out from the capture I'll take a look but send it to me directly.