From nobody@FreeBSD.org  Thu Mar 17 19:04:01 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 50CFB16A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 Mar 2005 19:04:01 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 21F5743D41
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 Mar 2005 19:04:01 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j2HJ40B9023761
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 17 Mar 2005 19:04:00 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j2HJ40qG023760;
	Thu, 17 Mar 2005 19:04:00 GMT
	(envelope-from nobody)
Message-Id: <200503171904.j2HJ40qG023760@www.freebsd.org>
Date: Thu, 17 Mar 2005 19:04:00 GMT
From: Zach Metzinger <zmetzing@warthog.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: smbfs getdirentries() failure causes CVS to fail
X-Send-Pr-Version: www-2.3

>Number:         78953
>Category:       kern
>Synopsis:       [smbfs] [patch] smbfs getdirentries() failure causes CVS to fail
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 17 19:10:02 GMT 2005
>Closed-Date:    Thu Aug 02 06:15:17 GMT 2007
>Last-Modified:  Thu Aug 02 06:15:17 GMT 2007
>Originator:     Zach Metzinger
>Release:        FreeBSD 4.10-RELEASE #0
>Organization:
>Environment:
FreeBSD infidel 4.10-RELEASE FreeBSD 4.10-RELEASE #0: Thu Sep 16 12:24:40 CDT 2004     zmetzing@infidel:/usr/src/sys/compile/INFIDEL  i386
>Description:
      I had my CVSROOT pointing to a directory on an smbfs mounted share (detailed below). My CVS local working repository was on a traditional ufs filesystem. When I ran cvs update on a specific subdirectory of my local working directory, CVS complained that it could not access the directory in the repository. I failed to capture the exact error message from CVS, but I do have the truss(1) output:

open("/remotefs/software/scm/Matlab/work/gpib",0x4,027757771374) = 4 (0x4)
fstat(4,0xbfbff410)                              = 0 (0x0)
fcntl(0x4,0x2,0x1)                               = 0 (0x0)
__sysctl(0xbfbff2c8,0x2,0x282c5c20,0xbfbff2c4,0x0,0x0) = 0 (0x0)
fstatfs(0x4,0xbfbff310)                          = 0 (0x0)
getdirentries(0x4,0x80c8000,0x1000,0x80c08f4)    = 3960 (0xf78)
getdirentries(0x4,0x80c8000,0x1000,0x80c08f4)    = 3960 (0xf78)
getdirentries(0x4,0x80c8000,0x1000,0x80c08f4)    = 3960 (0xf78)
getdirentries(0x4,0x80c8000,0x1000,0x80c08f4)    = 1848 (0x738)
getdirentries(0x4,0x80c8000,0x1000,0x80c08f4)    ERR#9 'Bad file descriptor'
lseek(4,0x0,0)                                   = 0 (0x0)
close(4)                                         = 0 (0x0)

Comparing this to a getdirentries() call on a non-problem directory, it seems that the difference is the last getdirentries() call returning with an error instead of just a read of length 0 (signalling the end of directory information).

Mounted share from OS=[Windows Server 2003 3790] Server=[Windows Server 2003 5.2] as:
//SOMEUSER@SOMESERVER/SOFTWARE on /remotefs/software (smbfs)

I then used a MS Windows version of CVS to add a new file to this repository directory. Now the problem doesn't happen and getdirentries() returns as expected:

open("/remotefs/software/scm/Matlab/work/gpib",0x4,02640) = 5 (0x5)
fstat(5,0xbfbff410)                              = 0 (0x0)
fcntl(0x5,0x2,0x1)                               = 0 (0x0)
__sysctl(0xbfbff2c8,0x2,0x282c5c20,0xbfbff2c4,0x0,0x0) = 0 (0x0)
fstatfs(0x5,0xbfbff310)                          = 0 (0x0)
getdirentries(0x5,0x80c8000,0x1000,0x80cd5d4)    = 3960 (0xf78)
getdirentries(0x5,0x80c8000,0x1000,0x80cd5d4)    = 3960 (0xf78)
getdirentries(0x5,0x80c8000,0x1000,0x80cd5d4)    = 3960 (0xf78)
getdirentries(0x5,0x80c8000,0x1000,0x80cd5d4)    = 2112 (0x840)
getdirentries(0x5,0x80c8000,0x1000,0x80cd5d4)    = 0 (0x0)
lseek(5,0x0,0)                                   = 0 (0x0)
close(5)                                         = 0 (0x0)

I then removed the new file from the CVS directory and got the same non-failure results as above. I have packet captures from this session for the failure case. Send me email and I will forward the capture file.

>How-To-Repeat:
            Unknown.. Hasn't happened again. Possibly happens on NT directory sizes of (exactly or multiples of) 13728 with nbytes = 3960. 
>Fix:
            Possibly ignore flaky behavior from Windows 2003 file server at end-of-directory, or could be a problem with the request on the FBSD side.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->bp 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Fri Mar 18 09:51:27 GMT 2005 
Responsible-Changed-Why:  
Boris, can you look at this? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78953 

From: Antony Mawer <fbsd@mawer.org>
To: bug-followup@FreeBSD.org, zmetzing@warthog.com
Cc: bp@FreeBSD.org
Subject: Re: kern/78953: smbfs getdirentries() failure causes CVS to fail
Date: Tue, 19 Apr 2005 00:27:57 +1000

 I've been pulling my hair out trying to track down problems with using
 rsync over smbfs that I believe is related to this issue. I have a
 Windows XP (SP1) machine that I've mounted via mount_smbfs:
 
     mount_smbfs -f 0400 -d 600 -u 0 -g 0 '//Antony@SPIKE/e$' /mnt
 
 and are then trying to rsync from the SMB-mounted /mnt to a local UFS
 partition:
 
     rsync -rW --progress /mnt /.disk3/rsync_test
 
 The output of the rsync command has numerous "Bad file descriptor"
 errors, such as (there are dozens more of these):
 
 > [root@gwsquish] ~$ rsync -rW --progress /mnt /.disk3/blah
 > building file list ...
 > rsync: readdir(mnt/LAPTOP_BACKUP/Software/old/Copied/Programs/encarta2003/Aref/Fonts): Bad file descriptor (9)
 > rsync: readdir(mnt/Media/Other Audio/MIDIs/Unsorted/Dark Forces MIDI Files): Bad file descriptor (9)
 > rsync: readdir(mnt/My Pictures/Birthdays/Family/Carol - 60th Birthday (2005-02-12)): Bad file descriptor (9)
 
 I've been tracing through the rsync source code and discovered that
 where it reads the directory contents using readdir(), all is well, and
 after the final directory is read and readdir() returns NULL, errno is
 set to 9 (which rsync checks at the end, and then reports the shown
 messages).
 
 Following through the readdir() routine, this seems to be arising from
 the getdirentries() call within readdir() -- at least, it's the only
 thing called within readdir() that has any code that might change errno.
 
 Creating a new file within
 LAPTOP_BACKUP/Software/old/Copied/Programs/encarta2003/Aref/Fonts on the
 Windows XP machine causes the error message to disappear; deleting that
 file makes it reappear again. Similarly, deleting one of the files from
 that directory and creating a blank text file under a different name
 causes the error to remain.
 
 Checking quickly, the first two of the directories listed above have 50
 files (plus . and ..) and no other directories within them. The third
 has 82 files (plus . and ..) and no directories within them. I checked
 some more and here are the results:
 
    * 3x with 50 files
    * 1x with 82 files
    * 1x with 67 files
 
 I created a new empty directory and created 0 byte text files in there,
 and then copied that file until the error occured. With 52 empty files
 in the directory I hit the error whilst doing:
 
     rsync -rW --progress /mnt/test /.disk3/blah
 
 Where /mnt/test was the directory on the Windows XP SMB mounted share
 containing the empty text files, and /.disk3/blah was a temporary
 directory used for testing. /.disk3/blah/test/ correctly contains 52
 empty text files at the end of the process....
 
 I can confirm this behaviour on both 4.7-RELEASE-p2 and 4.11-RELEASE-p3.
 
 If I can provide any further information in tracking this down and
 getting it fixed (testing patches etc), please let me know!
 
 Regards
 Antony Mawer

From: Antony Mawer <fbsd@mawer.org>
To: bug-followup@FreeBSD.org, zmetzing@warthog.com
Cc:  
Subject: Re: kern/78953: smbfs getdirentries() failure causes CVS to fail
Date: Tue, 19 Apr 2005 17:29:51 +1000

 Further to this, here's a snippet of the truss output from running the
 rsync command with the test directory of empty text files, showing the
 same error from getdirentries() as the original report:
 
 lstat("test/Copy (48) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (49) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 getdirentries(0x4,0x80e7000,0x1000,0x807f0d4)    = 2376 (0x948)
 lstat("test/Copy (5) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (50) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (51) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (6) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (7) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (8) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy (9) of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/Copy of New Text Document.txt",0xbfbfe090) = 0 (0x0)
 lstat("test/New Text Document.txt",0xbfbfe090)   = 0 (0x0)
 getdirentries(0x4,0x80e7000,0x1000,0x807f0d4)    ERR#9 'Bad file descriptor'
 write(2,0xbfbfdf40,46)                           = 46 (0x2e)
 lseek(4,0x0,0)                                   = 0 (0x0)
 close(4)                                         = 0 (0x0)
 
 Regards
 Antony

From: Chris Williams <psion@geekspace.com>
To: bug-followup@FreeBSD.org,  zmetzing@warthog.com
Cc:  
Subject: Re: kern/78953: smbfs getdirentries() failure causes CVS to fail
Date: Tue, 24 May 2005 22:40:47 -0400

 I've been having problems with my backups, which tar up files from an 
 smbfs-mounted WinXP volume, which I believe are related to this issue. I was 
 getting the 'Bad file descriptor' error for directories with the following 
 numbers of entries:
 
 331
 1147
 82
 52
 50
 
 Notably, three of these are sizes previously reported.
 
 In every case, adding one empty file to the directory fixed the problem.
 
 I'm running 4.11-STABLE (i386) circa May 19th, and the problem seems to have 
 existed in 4-STABLE since at least Oct 1 2002 (the date of the build I was 
 running before updating last week).
 
 My kernel is GENERIC + IPFW + IPDIVERT, no other tweaks.
 
 Hope this helps,
 
 Chris
 

From: "Jim Carroll" <jim@carroll.com>
To: <bug-followup@FreeBSD.org>,
	<zmetzing@warthog.com>
Cc:  
Subject: Re: kern/78953: [smbfs] smbfs getdirentries() failure causes CVS to fail
Date: Mon, 7 Nov 2005 17:10:41 -0500

 We've been tracking into this problem for the past several weeks, and only
 just realized there is a PR on it.
 
 The problem seems to be related to the number of objects in a folder.  The
 problem can very easily be re-created by creating 50 files in a samba share,
 and trying to rsync it to a FreeBSD 4.11 or Darwin box.
 
 # mount_smbfs -I [ipaddr w2k] '//Administrator@w2k/C$' /mnt
 # mkdir /mnt/dummy
 # cd /mnt/dummy
 # touch 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
 # rsync -rn /mnt/dummy /var/tmp
 
 Error message
 building file list ... rsync: readdir(.): Bad file descriptor (9)
 
 
 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);
 
 
 I'm working through the netsmb source code, but it's slow going.
 
 I ran the above example on 
 
 # uname -a
 FreeBSD 30.dhcp.hck.carroll.com 4.11-STABLE FreeBSD 4.11-STABLE #1: Tue Nov
 1 22:15:50 EST 2005
 jim@30.dhcp.hck.carroll.com:/usr/src/sys/compile/NC.DEBUG  i386
 
 
 We also ran it on a Darwin machine
 
 $ uname -a
 Darwin 94.dhcp.hck.carroll.com 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power Macintosh
 powerpc
 
 Both machines reported the same error.
 
 building file list ... rsync: readdir(.): Bad file descriptor (9)
 
 What's particularly interesting, is other utilities can successfully recurse
 into the directory without any problems.  I've written a small command line
 utility that does
 
 	opendir()
 	readdir()
 		lstat()
 
 which is basically what rsync does, I get no errors.  I've gone over rsync
 with gdb, and can't find anything too unusual going on.  
 
 Any pointers, crazy ideas, off the wall theories, etc... would be greatly
 appreciated.
 
 
 ---
 Jim C.          | Carroll-Net, Inc.
 201-488-4092    |
 www.carroll.com | Application Service Provider
 
 

From: "Jim Carroll" <jim@carroll.com>
To: <bug-followup@FreeBSD.org>,
	<zmetzing@warthog.com>
Cc:  
Subject: Re: kern/78953: [smbfs] smbfs getdirentries() failure causes CVS to fail
Date: Thu, 17 Nov 2005 18:08:15 -0500

 I've discovered the solution to the problem.  Apply this patch against
 smbfs_smb.c
 
 --- smbfs_smb.c	Wed Jan 28 01:21:01 2004
 +++ smbfs_smb.c.fix	Tue Nov 15 07:05:56 2005
 @@ -1224,8 +1224,10 @@ smbfs_smb_trans2find2(struct smbfs_fctx 
  		return error;
  	if ((error = md_get_uint16le(mdp, &tw)) != 0)
  		return error;
 -	if (ctx->f_ecnt == 0)
 +	if (ctx->f_ecnt == 0) {
 +		ctx->f_flags |= SMBFS_RDD_EOF | SMBFS_RDD_NOCLOSE;
  		return ENOENT;
 +		}
  	ctx->f_rnameofs = tw;
  	mdp = &t2p->t2_rdata;
  	if (mdp->md_top == NULL) {
 
 
 I've spent several weeks debugging smbfs and looking through packet traces.
 Here's what I've learned
 
 Smbfs compiled under FreeBSD 4.11-STABLE, creates a TRANS2_FIND_FIRST2
 requests with ctx->f_limit set to 52 by default (this is derived from
 (DIRBLKSZ/sizeof dirent)*4).
 
 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.
 
 ---
 Jim C.          | Carroll-Net, Inc.
 201-488-4092    |
 www.carroll.com | Application Service Provider
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Mon Apr 17 21:03:07 UTC 2006 
State-Changed-Why:  
Did this patch ever get committed? 


Responsible-Changed-From-To: bp->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Apr 17 21:03:07 UTC 2006 
Responsible-Changed-Why:  
Reassign at assignee's request due to current lack of time to work on FreeBSD. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78953 

From: "Jim Carroll" <jim@carroll.com>
To: <bug-followup@FreeBSD.org>,
	<zmetzing@warthog.com>
Cc:  
Subject: Re: kern/78953: [smbfs] [patch] smbfs getdirentries() failure causes CVS to fail
Date: Wed, 3 May 2006 21:01:14 -0400

 Just curious.  I submitted a patch last November, and it would appear this
 is not committed to source tree. Any chance it will make it into the next
 release?
 
 I've tested this patch extensively now.  If someone needs more data points
 to be satisfied it works, I be happy to provide them. Just let me know.
 
 ---
 Jim C.          | Carroll-Net, Inc.
 201-488-4092    |
 www.carroll.com | Application Service Provider
 
 
State-Changed-From-To: feedback->open 
State-Changed-By: linimon 
State-Changed-When: Thu May 4 02:27:05 UTC 2006 
State-Changed-Why:  
Apparently this patch has never been committed.  Submitter notes that he 
has been running with it for quite some time and recommends it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78953 

From: "Jim Carroll" <jim@carroll.com>
To: <bug-followup@FreeBSD.org>,
	<zmetzing@warthog.com>
Cc:  
Subject: Re: kern/78953: [smbfs] [patch] smbfs getdirentries() failure causes CVS to fail
Date: Wed, 24 May 2006 10:32:19 -0400

 If you're following this bug thread, I thought you'd appreciate a status
 update.
 
 I've been in contact with the release team at FreeBSD. They are overloaded
 with projects right now, and have advised me there isn't time to include
 this in the next release.  Stay tuned.
 
 Btw; this bug also exists in Mac OS-X (Darwin).
 
 ---
 Jim C.          | Carroll-Net, Inc.
 201-488-4092    |
 www.carroll.com | Application Service Provider
 
 
Responsible-Changed-From-To: linimon->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Jun 15 06:51:03 UTC 2006 
Responsible-Changed-Why:  
Reassign from me back to the pool; I only assigned it to myself to track 
the feedback. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78953 

From: "Jim Carroll" <jim@carroll.com>
To: <bug-followup@FreeBSD.org>,
	<zmetzing@warthog.com>
Cc:  
Subject: Re: kern/78953: [smbfs] [patch] smbfs getdirentries() failure causes CVS to fail
Date: Wed, 30 Aug 2006 10:05:37 -0400

 More update.
 
 No news on the FreeBSD team, but I've been advised that the patch is
 scheduled to be included in the Netbsd-4 release later this year.
 
 Stay tuned.
 
 ---
 Jim C.          | Carroll-Net, Inc.
 201-488-4092    |
 www.carroll.com | Application Service Provider
 
 

From: Antony Mawer <fbsd@mawer.org>
To: bug-followup@FreeBSD.org,  zmetzing@warthog.com
Cc: jim@carroll.com,  linimon@freebsd.org,  bp@freebsd.org, 
 tjr@freebsd.org
Subject: Re: kern/78953: [smbfs] [patch] smbfs getdirentries() failure causes
 CVS to fail
Date: Wed, 15 Nov 2006 18:47:13 +1100

 (CC'ing people in the PR, and a few others who have had to do with 
 smbfs, in the hope of getting this committed...)
 
 Following up on this, I've finally gotten around to testing the patch by 
 Jim Carroll. I ran a simple rsync with before and after the patch, with 
 the results being what I would expect (slightly anonymised).
 
 First, the run with a 6.2-PRERELEASE as of about a week ago, showing the 
 Bad file descriptor errors that were previously being seen:
 
 > [root@hostname] ~$ mount /media/smb1
 > [root@hostname] ~$ rsync -a --dry-run /media/smb1/ /tmp
 > rsync: readdir("/media/smb1/Profiles/USER1/Application Data/Microsoft/MSN Messenger/0123456789"): Bad file descriptor (9)
 > rsync: readdir("/media/smb1/Profiles/USER2/Application Data/Macromedia/Dreamweaver 8/Configuration/Temp/FlashElements/ImageViewer"): Bad file descriptor (9)
 > rsync: readdir("/media/smb1/Profiles/USER3/Desktop/docs"): Bad file descriptor (9)
 > rsync: readdir("/media/smb1/Programs/Programming/SDK"): Bad file descriptor (9)
 > rsync: readdir("/media/smb1/Users/USER1/packages"): Bad file descriptor (9)
 > rsync error: some files could not be transferred (code 23) at main.c(892) [sender=2.6.8]
 > [root@hostname] ~$
 
 
 The next run is after patching sys/fs/smbfs/smbfs_smb.c with Jim's 
 patch, and then rebuilding/reinstalling the kernel and rebooting:
 
 > [root@hostname] ~$ rsync -a --dry-run /media/smb1/ /tmp
 > [root@hostname] ~$
 
 I also did a comparison of the file & directory listing both before and 
 after the patching process, by doing a:
 
      rsync -av --dry-run /media/smb1 /tmp > (before|after)-patch.txt
 
 Comparing the output of these two, the only difference was in the 
 overall size, as a result of a file being updated on the server in 
 between the two rsync ouputs:
 
 [root@hostname] ~$ diff -u2 before-patch.txt after-patch.txt
 --- before-patch.txt    Wed Nov 15 18:40:03 2006
 +++ after-patch.txt     Wed Nov 15 18:25:23 2006
 @@ -136903,3 +136903,3 @@
 
   sent 3505335 bytes  received 821426 bytes  163274.00 bytes/sec
 -total size is 80453796677  speedup is 18594.46
 +total size is 80453796144  speedup is 18594.46
 
 So I'm satisfied that the behaviour of smbfs is not at all impacted in 
 any way, aside from resolving the error message that was being generated.
 
 If anyone requires any further tests, please let me know - otherwise it 
 seems that this looks like a fix that should be committed. It's already 
 gone into NetBSD 4.x, as Jim mentioned. Anyone willing to commit this...?
 
 Cheers
 Antony
State-Changed-From-To: open->patched 
State-Changed-By: bmah 
State-Changed-When: Sat Nov 18 18:59:23 UTC 2006 
State-Changed-Why:  
This appears to have been patched by bp@ in src/sys/fs/smbfs/smbfs_fs.c 
revision 1.16.  Updating bug state. 

I know nothing else about this bug; I only know about it because someone 
asked re@ about it and I had to review the audit trail. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=78953 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/78953: commit references a PR
Date: Thu,  2 Aug 2007 06:02:15 +0000 (UTC)

 rodrigc     2007-08-02 06:02:07 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/fs/smbfs         smbfs_smb.c 
   Log:
   MFC 1.16:
   
      Fix interaction with Windows 2000/XP based servers:
   
      If the complete reply on the TRANS2_FIND_FIRST2 request fits exactly
      into one responce packet, then next call to TRANS2_FIND_NEXT2 will return
      zero entries and server will close current transaction.  To avoid
      subsequent errors we should not perform FIND_CLOSE2 request.
   
   PR:             78953
   Submitted by:   Jim Carroll <jim carroll com>
   Requested by:   Antony Mawer <fbsd-fs mawer org>,  Peter <peter pean org>
   =============================================================================
   
   Revision  Changes    Path
   1.15.2.1  +3 -1      src/sys/fs/smbfs/smbfs_smb.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: rodrigc 
State-Changed-When: Thu Aug 2 06:14:59 UTC 2007 
State-Changed-Why:  
Patch MFC'd to RELENG_6. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78953 
>Unformatted:
