Date: Wed, 15 Nov 2006 07:50:06 GMT From: Antony Mawer <fbsd@mawer.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/78953: [smbfs] [patch] smbfs getdirentries() failure causes CVS to fail Message-ID: <200611150750.kAF7o6mE064668@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/78953; it has been noted by GNATS.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611150750.kAF7o6mE064668>