Bug 2533 - DIR command not working properly in OS/2 DOSBOX and Win98 DOS app fails to run
DIR command not working properly in OS/2 DOSBOX and Win98 DOS app fails to run
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.12
x86 OS/2
: P3 critical
: none
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-23 03:33 UTC by Guenter Kukkukk
Modified: 2005-08-24 10:16 UTC (History)
0 users

See Also:


Attachments
failing samba3 sniff (7.18 KB, application/octet-stream)
2005-03-23 17:06 UTC, Guenter Kukkukk
no flags Details
winxp ethereal sniff for comparison (10.24 KB, application/octet-stream)
2005-03-23 17:07 UTC, Guenter Kukkukk
no flags Details
Patch part 1. (555 bytes, patch)
2005-03-23 19:08 UTC, Jeremy Allison
no flags Details
Patch part 2 (1.38 KB, patch)
2005-03-23 19:22 UTC, Jeremy Allison
no flags Details
Running FOX Pro from Samba drive.Client is Windows'98 (9.53 KB, application/octet-stream)
2005-03-24 01:07 UTC, Alex Masterov
no flags Details
Proposed patch. (533 bytes, patch)
2005-03-25 12:49 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guenter Kukkukk 2005-03-23 03:33:27 UTC
Hello to the samba team,

the following bug was not seen in version 3.0.10.
It was first recognized on 3.0.12 and is still in latest svn build
3.0.14pre1-SVN-build-5991.

It was reported and also heavily tested by SambaOS/2 team member
Alex Masterov. I did test part of the bug inside an OS/2 DOSBOX. 

Description:
A shared samba drive might contain files in all uppercase, all lowercase
or mixed case.
Inside an OS/2 DOSBOX, a simple 'dir' shows all files in their right case.
But a selective 'dir *.sys' (or similar) does not show all or no file(s).
For simplicity, let us assume the share contains only the following 2 files:
  CONFIG.SYS
  confi1.sys
A 'dir *.sys' does only show CONFIG.SYS
The same holds true for 'dir co*'

But a command like 'type confi1.sys' dumps the file's contents, so it
can be accessed.

CONCLUSION:
All lowercase filenames cannot be listet, when some kind of 
wildcard dir command is used.

A similar problem was tested by Alex Masterov on Win98:
All "FoxPro 2.6 for DOS" files are located on a samba share.
When FoxPro (DOS App) is started, it reports "Cannot locate
the desired version of foxpro" and exits.
A check on the samba (FreeBSD) side revealed, that all FoxPro
files were stored in lowercase. When they all were converted
to uppercase, the FoxPro Error is gone and the app is running.
Again - also this error was not seen in 3.0.10, but in 3.0.12
and the latest svn build.

If any further info is needed, please drop me a note.
Unfortunately i have no "real" DOS machine running...

Best wishes to the samba team.

Alex Masterov and Guenter Kukkukk - team SambaOS/2
Comment 1 Jeremy Allison 2005-03-23 10:47:43 UTC
Can you send me an ethereal capture trace of this please. I need this
as a priority if we're to fix it in 3.0.13, if I don't get it today it'll
have to wait for 3.0.14 at the earliest.
Jeremy.
Comment 2 Guenter Kukkukk 2005-03-23 17:06:53 UTC
Created attachment 1101 [details]
failing samba3 sniff
Comment 3 Guenter Kukkukk 2005-03-23 17:07:40 UTC
Created attachment 1102 [details]
winxp ethereal sniff for comparison
Comment 4 Guenter Kukkukk 2005-03-23 17:10:03 UTC
Hi Jeremy,

i attach 2 ethereal captures
  - failing one on samba3: kukks_samba3_os2_dosbox_dir_wild.cap
  - working one against WinXP-ProSP2: kukks_winxp_os2_dosbox_dir_wild.cap
the WinXP capture had to be done in promiscous mode on the linux box.

I captured the whole SessSetup and Negprot stuff, too - so you can
also see the used protocol (LANMAN2.1).

On the os2 machine i used
  net use z: \\linux200\testgk  for the samba3 sniff - and later
  net use z: \\winxp1\samba     for the winxp sniff

The used share in both cases contained the following 3 files
(but diff. timestamps):
ramfs    cmd
confi1   sys
CONFIG   SYS

Then inside an os2 DOSBOX, i entered the following commands:
dir z:
dir z:*.sys
dir z:*.cmd

---------------------------------------------
output from samba3:

C:\ 0 >dir z:
The volume label in drive Z is testgk.
The Volume Serial Number is 176E:09C2.
Directory of Z:\                       ALSO NOTE: . and .. are not shown.
ramfs    cmd       116   9.03.01  4.37            Files are shown case sensitive
confi1   sys       321  27.12.04  6.21
CONFIG   SYS     17054  30.12.04  7.12
       3 file(s)      17491 bytes used
                 2146402304 bytes free
C:\ 0 >dir z:*.sys
The volume label in drive Z is testgk.
The Volume Serial Number is 176E:09C2.
Directory of Z:\
CONFIG   SYS     17054  30.12.04  7.12
       1 file(s)      17054 bytes used
                 2146402304 bytes free
C:\ 0 >dir z:*.cmd
The volume label in drive Z is testgk.
The Volume Serial Number is 176E:09C2.
SYS0002: The system cannot find the file specified.

------------------------------------------------------
Now the winxp stuff:

C:\ 0 >dir z:
The volume label in drive Z is NO NAME
The Volume Serial Number is 04C3:8BD1.
Directory of Z:\
.            <DIR>      23.03.05 23.12
..           <DIR>      23.03.05 23.12
CONFI1   SYS       321  27.12.04  6.21
CONFIG   SYS     17054  30.12.04  7.12
RAMFS    CMD       116   9.03.01  4.37
       5 file(s)      17491 bytes used
                 2146402304 bytes free

C:\ 0 >dir z:*.sys
The volume label in drive Z is NO NAME
The Volume Serial Number is 04C3:8BD1.
Directory of Z:\
CONFI1   SYS       321  27.12.04  6.21
CONFIG   SYS     17054  30.12.04  7.12
       2 file(s)      17375 bytes used
                 2146402304 bytes free

C:\ 0 >dir z:*.cmd
The volume label in drive Z is NO NAME
The Volume Serial Number is 04C3:8BD1.
Directory of Z:\
RAMFS    CMD       116   9.03.01  4.37
       1 file(s)        116 bytes used
                 2146402304 bytes free
------------------------------------------------

If you need any further info, please drop me a note.
Best wishes.
Guenter
Comment 5 Jeremy Allison 2005-03-23 17:32:11 UTC
Ok - cool ! This is very good info. I do see Samba returning the files on the
disk for the OS/2 requests. Hmmmm.
What I'd like to see for comparison is a sniff of an OS/2 client against a Windows
or OS/2 server - to see how it looks when it's working.
Jeremy.
Comment 6 Jeremy Allison 2005-03-23 17:34:16 UTC
Oh - sorry - that's what the WinXP sniff was. Now I understand - thanks.
I have the info I need now - thanks.
Jeremy.
Comment 7 Jeremy Allison 2005-03-23 19:08:32 UTC
Created attachment 1103 [details]
Patch part 1.

First patch for this problem.
Jeremy.
Comment 8 Jeremy Allison 2005-03-23 19:22:17 UTC
Created attachment 1104 [details]
Patch part 2

The combination of these two fix the problem I think...
Jeremy.
Comment 9 Jeremy Allison 2005-03-23 19:23:16 UTC
I've checked these two fixes into SVN. I think this fixes the problem.
Please test.
Jeremy.
Comment 10 Guenter Kukkukk 2005-03-23 21:47:02 UTC
Hi Jeremy,

i did some short testing and the os2 DOSBOX error is gone. :-)
See the new output below.
Alex will check the win98 FoxPro problem and he will drop me a note.

But - when i did that testing - by the way i also tried a simple
os2 copy from a samba3 share to a local drive to check 
upper / lowercase stuff.
That copy of 1 single file fails!
I already sniffed that copy and a similar one when doing it from a
winxp share. May be some SMB buffer overflow / corruption has happened,
unfortunately i have nearly no time at the moment, to dig deeper.
(Urgent customer work is waiting...)

Should i open a new bug?

Best wishes.
Guenter

-----------------------
os2 DOSBOX output after patching:

C:\ 0 >dir z:
The volume label in drive Z is testgk.
The Volume Serial Number is 176E:09C2.
Directory of Z:\
.            <DIR>      23.03.05 22.56
..           <DIR>      22.03.05 18.01
RAMFS    CMD       116   9.03.01  4.37
CONFI1   SYS       321  27.12.04  6.21
CONFIG   SYS     17054  30.12.04  7.12
       5 file(s)      17491 bytes used
                 2146402304 bytes free

C:\ 0 >dir z:*.sys
The volume label in drive Z is testgk.
The Volume Serial Number is 176E:09C2.
Directory of Z:\
CONFI1   SYS       321  27.12.04  6.21
CONFIG   SYS     17054  30.12.04  7.12
       2 file(s)      17375 bytes used
                 2146402304 bytes free

C:\ 0 >dir z:*.cmd
The volume label in drive Z is testgk.
The Volume Serial Number is 176E:09C2.
Directory of Z:\
RAMFS    CMD       116   9.03.01  4.37
       1 file(s)        116 bytes used
                 2146402304 bytes free
Comment 11 Jeremy Allison 2005-03-23 23:07:31 UTC
Yes, please open a new bug and attach the traces. I'll close this one out
now.
Thanks,
Jeremy.
Comment 12 Guenter Kukkukk 2005-03-23 23:31:48 UTC
I think, i should add some comments to my latest description.
Alex has also tested the os2 DOSBOX, it seems to be fine now.
But the Win98 FoxPro problem is still there, he is taking ethereal
sniffs now!

May be, it's not publicly known. OS/2 has a usual commandline
text window - the shell running inside is normally cmd.exe. But
the shell can be changed - i mostly use 4os2.exe, which has much more
features. (but also bash, ksh ... is possible)

In addition, one can also open a DOSBOX, in which a DOS emulation
is running (usually 8.3 filenames only). But also native DOS
versions can be loaded into such a beast, which isn't used too often.
This error 2533 was related to testing inside a DOSBOX!

The new "copy 1 file" error i mentioned before is related to a usual
os2 commandline window, which can also display long filenames in upper,
lower, mixed case (but os2 is case insensitive like windows).

I will open a new bug.

Guenter
Comment 13 Guenter Kukkukk 2005-03-24 01:07:04 UTC
Cause the Win98 FoxPro issue is still unresolved, the bug should be reviewed 
again.
Alex wants to add some notes and another ethereal sniff.
Comment 14 Alex Masterov 2005-03-24 01:07:50 UTC
Created attachment 1110 [details]
Running FOX Pro from Samba drive.Client is Windows'98

Here is attempt to run FoxPro 2.6 from Samba 3.0.14pre1-SVN-build-6031. Client
is Windows 98. I've run fox.exe. fox.exe detects 386+ processor and attempts to
find and run protected-mode foxprox.exe. But it can not do this on 3.0.12 and
3.0.14. 
On 3.0.10 everything was OK.
Comment 15 Jeremy Allison 2005-03-24 13:34:43 UTC
Ok, I can see the problem. The search request is requesting unicode strings,
we're replying with ASCII.... but still setting the unicode bit ! This is
seriously screwed up...
I'll check into it asap.
Jeremy.
Comment 16 Jeremy Allison 2005-03-25 12:49:29 UTC
Created attachment 1121 [details]
Proposed patch.

This should fix the foxpro bug. It forces the UNICODE flag to be removed on a
SMBsearch reply.
Jeremy.
Comment 17 Jeremy Allison 2005-03-25 12:49:59 UTC
Closing this "dual" bug out. Any more - please log a new bug :-).
Jeremy.
Comment 18 Alex Masterov 2005-03-27 23:55:32 UTC
Problem still exists on 3.0.14pre1-SVN-build-6092.
I've opened new BUG #2551
Comment 19 Gerald (Jerry) Carter 2005-08-24 10:16:19 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.