We use MS DOS 7 ala Win98 SE and the M$ client for DOS to logon to Samba 3.0.13
Debian Stable package from samba.org. Also one other unique thing, we have
XCOPY32.EXE copied as XCOPY.EXE thus it is really XCOPY32.EXE we are executing,
just as XCOPY.EXE. ;-)
Example of failing line of code...
echo f|xcopy u:\foo\bar.txt h:\file.txt
where U: is the drive mapped to the server and H: is a local RAM drive using
XFSDSK. The file is copied over and over and over. This is not consistent for
all files on the server, others copy correctly only one time from the server
drive to the RAM drive.
Please advise if I should, for example, get a log 10 of this behavior or something.
This is a known bug we fixed for 3.0.14a.
I just downloaded the Debian 3.0.14a packages from samba.org this evening, and
this exact problem still exists with that version. I just dropped back to 3.0.11
Debian packages on that server. Please advise what I can do to assist with this
Send in a tcpdump or ethereal capture file showing the network traffic between
client and server in this case please.
Created attachment 1178 [details]
Ethereal trace of DOS copying one file forever - Zipped
Ethereal trace of DOS copying one file forever
Created attachment 1179 [details]
Ethereal trace of DOS copying one file Working!
Working test is against 3.0.11 server
Created attachment 1197 [details]
Log level 10 of the copy forever issue
Ok, quick analysis is the difference between working and not is the
server cookie which is 0x72A000080 on working and 0x8FFFFFFFF when not
(hmmm. looks like a -1 thing to me :-).
What filesystem are you using ? Looks like TellDir is returning something
bad at end-of-directory.
Created attachment 1200 [details]
Please try this fix against 3.0.14a - I think it should fix it. Sorry for the
bug, it was some old crufty code that needed fixing up for old SMBsearch calls.
Reported as fixed.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.