Bug 2337 - OS/2 dir command on empty subdir returns error 161 - also OS/2 xcopy is affected
Summary: OS/2 dir command on empty subdir returns error 161 - also OS/2 xcopy is affected
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.9
Hardware: All OS/2
: P3 normal
Target Milestone: none
Assignee: Jim McDonough
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-02-11 19:38 UTC by Guenter Kukkukk
Modified: 2005-08-24 10:19 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Guenter Kukkukk 2005-02-11 19:38:34 UTC
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.

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) :-)


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

   srvstr_get_path() calls 

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:

which is mapped in errormap.c

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:

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

static NTSTATUS check_path_syntax(const char *name)
 while (*name == '\\')
 if (strequal(name, "."))
 else if (strequal(name, ".."))
 return NT_STATUS_OK;

Best wishes to the samba developers.

Guenter Kukkukk
Entwicklungsbuero fuer Informationstechnologien
Damaschkestr. 24
10711 Berlin - Germany
Comment 1 Jim McDonough 2005-03-16 09:15:16 UTC
fix checked in by jra.  Please test
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:19:46 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.