When using the OS/2 "xcopy /S/E" command on large directory trees, it fails when it encounters empty subdirs. Solution: in file .../smbd/trans2.c -> function static int call_trans2findfirst() ... around line 1500 in latest svn build 5340 ... /* * If there are no matching entries we must return ERRDOS/ERRbadfile - * from observation of NT. */ if(numentries == 0) { dptr_close(&dptr_num); - return ERROR_DOS(ERRDOS,ERRbadfile); + return ERROR_DOS(ERRDOS,ERRnofiles); } ... os2 needs ERRnofiles, if it was a valid wildcard "*" search and the path was correct at all. WinNt, w2k also return this, when being accessed from an os2 or windows client! I have written a small os2 applet to check this special situation against samba, winnt and win2k (w2k3 has not been tested). Samba is the only one, which returns "ERRbadfile", all others return "ERRnofiles". This change has been heavily tested by team SambaOS/2 - and it should not break any other client. (hopefully) It was not tested against a w2k3 server. btw - this fix is _not_ related to the error code 161 (0xa1), which is returned, when a "dir" is done on an empty subdir (using cmd.exe). I'll post another bugfix, which will address that 161 error, because that one also affects xcopy in some ugly way. btw - this bug and the 161 bug might also affect Win98 systems (?) Best wishes to the samba team. Guenter Kukkukk Entwicklungsbuero fuer Informationstechnologien Damaschkestr. 24 10711 Berlin - Germany
Checked in patch. Thanks! Please test latest svn.
Jim, I'm reopening this bug. This is not correct - the original code is correct. I have just done an ethereal trace of a Win9x client doing a wildcard findfirst against a Win2k3 server and it returns ERRDOS/ERRbadfile *NOT* ERRDOS/ERRnofiles Also, changing the code without changing the comment is *bad* (and misleading :-). I'm going to revert this fix. I can add an OS/2 "special" (ie. only return this for OS/2) but the current code was correct for Win9x. Jeremy.
Created attachment 1041 [details] Fix I've applied. This is what I've checked in. I'm pretty sure this is the correct fix. It seems this error code is protocol level dependent. Jeremy.
I think this is now fixed. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.