When using the os2-shell cmd.exe and a "dir" is done on an
empty directory (samba share) - an error 161 (0xa1) is returned. 
(Truncated) Output:
...
Directory of Z:\smbtst\empty

11.02.05  20.12      <DIR>           0  .
13.12.04  22.41      <DIR>        4097  ..
SYS0317: The system cannot find message  0161
in message file OSO001.MSG.
...

NOTE:
Most of the following stuff assumes that the bug 2335 has already
been fixed!

This glitch also affects the os2 xcopy command in a very
ugly way, when a very large file tree is copied from a samba
share to os2 local. 
Hundreds of files (lots of megabytes) could be
transfered without error ... but then this samba glitch might
bite you (always reproducible, so ethereal could catch it) :-)

Description:

Many samba functions including
 - call_trans2findfirst() 
 - call_trans2findnext()
call the function srvstr_get_path() in .../smbd/reply.c

   srvstr_get_path() calls 
       check_path_syntax()

Beside other stuff check_path_syntax() checks for a string
like "." and "..". 
(which could be the "current dir" or the "parent dir")

When the os2 (cmd.exe) "dir" is issued on an empty subdir
or when xcopy is traversing a large file tree, at some point
of execution 'a follow up pointer (directory file ptr) ".." '
is passed to call_trans2findnext().
And then check_path_syntax() signals an error condition!
This leads to error 161 (0xa1) and the xcopy cmd is aborted!
This behaviour is not seen on WinNT, Win2000.

A quick and **dirty** temporary hack to 
.../smbd/trans2.c -> function call_trans2findnext()
may show this -> "dir" and "xcopy" are now working very, very well...

Around line 1582 in latest svn revision 5340
....
  *mask = *directory = *resume_name = 0;

  srvstr_get_path(inbuf, resume_name, params+12, sizeof(resume_name), -1, STR_T\
ERMINATE, &ntstatus, True);
  if (!NT_STATUS_IS_OK(ntstatus)) {
    /*    return ERROR_NT(ntstatus); */ !!!!!!!!!!!!!!! HACK !!! UNCOMMENT
  }
......

I'm not able to oversee all the needed stuff around srvstr_get_path(),
so i have no solution at the moment.

btw - when working together with tridge on the same stuff in samba 4.0,
this os2 error condition has never been seen....

If needed, i can supply ethereal sniffs which detail this bug.

Additional note:
When i was testing this stuff in December 2004, i realized, that
ethereal was returning a somewhat strange error regarding 161.

-------- mail to the ethereal developers on 2 Dec 2004:
...
the used version is "ethereal-0.10.3-15.9" on SuSE 9.1.

When sniffing samba smb traffic, I got the following ethereal output:
   Error: Unknown DOS error (a1)

In samba 3.0.9 ...../source/smbd/reply.c
you may note some statement like:
     ret = NT_STATUS_OBJECT_PATH_SYNTAX_BAD;

which is mapped in errormap.c
  ....
  {ERRDOS,  161,  NT_STATUS_OBJECT_PATH_INVALID},
  {ERRDOS,  ERRbadpath, NT_STATUS_OBJECT_PATH_NOT_FOUND},
  {ERRDOS,  161,  NT_STATUS_OBJECT_PATH_SYNTAX_BAD},
  ....

The Microsoft MSDN Help says:
161    The specified path is invalid.     ERROR_BAD_PATHNAME

OS/2 bseerr.h:
#define ERROR_BAD_PATHNAME      161
...
---------------- end of mail to ethereal developers


Just this from samba 3.0.0:
-----------------
from samba 3.0.0 - afaik at that time UNICODE was not implemented into samba:
smb/reply.c

......
/****************************************************************************
 Ensure we check the path in the same way as W2K.
****************************************************************************/

static NTSTATUS check_path_syntax(const char *name)
{
 while (*name == '\\')
  name++;
 if (strequal(name, "."))
  return NT_STATUS_OBJECT_NAME_INVALID;
 else if (strequal(name, ".."))
  return NT_STATUS_OBJECT_PATH_SYNTAX_BAD;
 return NT_STATUS_OK;
}
---------------------------------

Best wishes to the samba developers.

Guenter Kukkukk
Entwicklungsbuero fuer Informationstechnologien
Damaschkestr. 24
10711 Berlin - Germany