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

[Jim Carroll]

Hi, hope ya'll don't mind a follow-up question on my qwest to solve smbfs,
but I have an SMB protocol question.  Let me summarize what I've discovered.


Smbfs compiled under FreeBSD 4.11-STABLE, creates TRANS2_FIND_FIRST2
requests with USHORT SearchCount set to 52 by default (which is DIRBLKSZ*4).


If you perform this request on a directory with exactly 50 files (plus '.'
and '..' for a total of 52), 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.  (here's my question...)

The response returns a SearchCount of zero and an EndOfSearch code of zero.
My question is, is this to be considered EndOfSearch?  

Note: I tried to force a FIND_CLOSE2 after the TRANS2_FIND_NEXT2 call, and I
get my old friend, BadFid (bad file descriptor).

I found a solution, which is to set "SMB_RDD_EOF | SMB_RDD_NOCLOSE" after
getting back a zero SearchCount, but I'm not sure what the protocol
implication of this is?  Does it mean I've left an open file handle on the
server that will eventually build up and consume some sort of open file
table entries?

---
Jim C.          | Carroll-Net, Inc.
201-488-4092    |
www.carroll.com | Application Service Provider
> -----Original Message-----
> From: Michael B Allen [mailto:mba2000 at ioplex.com]
> Sent: Tuesday, November 08, 2005 8:26 PM
> To: Jim Carroll
> Cc: samba-technical at lists.samba.org
> Subject: Re: rsync: readdir(.): Bad file descriptor (9)
> 
> 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.