[Samba] BUG: 2.2.6 and dos recusive filecopy

[nicolaig]

(non-HTML this time! Sorry!)

Hi!

I've been using samba for some time now with about 20 users and with
remote installation of Windows XP from dos (TFTPboot image with dos
network drivers - ms client 1.6c).

On all releases (up to, and including 2.2.5) a recursive xcopy (from
dos) copied all files normally.

When I upgraded to samba 2.2.6, the recursive xcopy (win98 version of
xcopy.exe, copying from a mapped drive) only copied about half  the
files, skipping (for me, all had the same attributes/persmissions)
random files from random sub-directories.  When I moved the directory i
was copying to another share, it copied only 11 files of about 50.  I
later made a 'make revert', and with 2.2.5 everything was back to normal
and working.  If I copied the files manually before starting the winxp
install from dos (from the share), the setup seemed to stop, complaining
about missing files.  Everytime I ran my install-script, it was ALWAYS
the same files that were missing.


I am running Red Hat Linux 7.2.2 (kernel 2.4.9-34)



Another issue:  I sometimes get these problems:

[2002/10/29 12:54:34, 0] smbd/service.c:make_connection(384)
  root logged in as admin user (root privileges)
[2002/10/29 12:56:13, 0]
rpc_server/srv_samr.c:api_samr_set_userinfo(670)
  api_samr_set_userinfo: Unable to unmarshall SAMR_Q_SET_USERINFO.
[2002/10/29 13:01:13, 0] lib/util_sock.c:read_data(436)
  read_data: read failure for 4. Error = Connection reset by peer

and:
[2002/10/29 13:40:06, 0] smbd/service.c:make_connection(384)
  root logged in as admin user (root privileges)
[2002/10/29 13:41:00, 0] smbd/oplock.c:oplock_break(796)
  oplock_break: receive_smb timed out after 30 seconds.
  oplock_break failed for file I386/$oem$/$1/sysprep/prepare.cmd (dev =
811, inode = 1652860, file_id = 456).
[2002/10/29 13:41:00, 0] smbd/oplock.c:oplock_break(868)
  oplock_break: client failure in oplock break in file
I386/$oem$/$1/sysprep/prepare.cmd
[2002/10/29 13:41:00, 0] smbd/reply.c:reply_lockingX(4489)
  root logged in as admin user (root privileges)


any clues?


Nicolai Grødum