The remaining copy is the same size as source but corrupted.
WinXP logs an obscure NetBT Event ID 4322, which says
"NetBT could not process a request, because at least one
OutOfResources-Exception occurred in the last hour".
One can reproduce this error anytime if one chooses a big enough
file and copies it a second time before the first copy is done.
Samba 3.0.24 does not have this bug.
When a double copy fails there is this line in full_audit log
at the moment the errors pop up:
Jul 16 14:52:15 p92 smbd_audit: [2007/07/16 14:52:15, 0]
lib/util_sock.c:read_data(534)
Jul 16 14:52:15 p92 smbd_audit: read_data: read failure for 4 bytes
to client 172.24.204.176. Error = Connection reset by peer
Is this a known problem ?
Can I produce more diagnostics to help fix it ?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
Open a bug and attach an ethereal/wireshare network trace please.
Jeremy.
I'm having the exact same issue with 3.0.25b, didn't happen with
previous versions.
It seems to be happening randomly.
I've been tracking this same problem and managed to get a Wireshark
capture, so I posted it to
https://bugzilla.samba.org/show_bug.cgi?id=4796. If there's any other
information I can provide or testing I can perform, please let me
know.
Josh Kelley
I've just posted a fix for this as an attachment for this bug (#4796).
If someone would like to test it for 3.0.25c I'd be very grateful.
Thanks,
Jeremy.
Hi,
I can confirm that a re-build of the current SUSE 3.0.25b RPMs plus
today's diff between SAMBA_3_0_RELEASE and SAMBA_3_0_25 fixes the
strange file corruption problem I was seeing with LIB.EXE from
VisualStudio6 working on a Samba share. Though this was already true
with yesterdays diff, but didn't work with a diff from last week.
Franz.
Great - thanks for the update. I'm hoping I've now got this
right for 3.0.25c.
Thanks,
Jeremy.
Ok, since it seems you are heading for a 3.0.25c release soon, I'd
better report this little build failure with the python stuff:
building 'smb' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -march=i586 -mtune=i686
-fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -O2 -g -m32 -march=i586
-mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -DIDMAP_RID_SUPPORT_TRUSTED_DOMAINS
-D_SAMBA_BUILD_=3 -fPIC -I/usr/include/python2.4 -c python/py_smb.c -o
build/temp.linux-i686-2.4/python/py_smb.o -O2 -g -m32 -march=i586
-mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -DIDMAP_RID_SUPPORT_TRUSTED_DOMAINS
-D_SAMBA_BUILD_=3 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLDAP_DEPRECATED -O2 -g -m32
-march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE -DIDMAP_RID_SUPPORT_TRUSTED_DOMAINS
-D_SAMBA_BUILD_=3 -Iinclude -I./include -I. -I. -I./lib/replace
-I./lib/talloc -I./tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-DLDAP_DEPRECATED -I/home/fsirl/BUILD/samba-3.0.25b/source/lib
-D_SAMBA_BUILD_=3
In file included from /usr/include/python2.4/Python.h:8,
from ./python/py_common.h:33,
from ./python/py_smb.h:24,
from python/py_smb.c:21:
/usr/include/python2.4/pyconfig.h:838:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from /usr/include/stdio.h:28,
from ./lib/replace/replace.h:39,
from include/includes.h:29,
from ./python/py_common.h:24,
from ./python/py_smb.h:24,
from python/py_smb.c:21:
/usr/include/features.h:154:1: warning: this is the location of the
previous definition
python/py_smb.c: In function ‘py_smb_connect’:
python/py_smb.c:51: error: wrong type argument to unary exclamation mark
python/py_smb.c: In function ‘py_smb_session_request’:
python/py_smb.c:71: warning: assignment discards qualifiers from pointer
target type
error: command 'gcc' failed with exit status 1
make: *** [python_ext] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.90950 (%build)
This is on SLES10SP1 with gcc-4.1.2 and python-2.4.2.
Franz
Sorry, but I have to take back my words, partly at least :-( .
Today the corruption problem was back when I compiled our SW on a samba
share. Now this got me really confused, because yesterday I did the
"gmake clean all" procedure for our SW at least a dozen times, and
everytime it was OK. But today already on the first try linking would
bail out because LIB.EXE generated a corrupted library.
What the heck I thought, why does it fail again. As a first measure I
rebuilt samba with todays additional fix to locking.c, but this didn't
change anything. Then, as a preparation to run a tcpdump, I looked at
the smbd process responsible for my share with lsof. Hmm, I wondered,
why does it use "netbios-ssn" as a local port, my PC is running uptodate
WXPSP2 (german, without IE7), shouldn't it use "microsoft-ds" then?
Ok, disconnected and reconnected the share, and sure enough the
connection to the share would use "microsoft-ds" now. Restarted the
build of our SW, and voila! everything is fine now and the SW builds
until the end.
So this corruption only happens for "netbios-ssn"/port 139 connections
now (? not sure about this, but I can try with original 3.0.25b too if
you want), but with "microsoft-ds"/port 445 connections all works like a
charm.
Is this enough information for you or do you want me to do some smbd
debug and/or tcpdump debugging?
Franz.
Separate bugzilla bug please. Also - who uses the python bindings ?
I know Jerry was wanting to remove them as they're not currently
used/properly maintained.
Jeremy.