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
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.
Created attachment 1101 [details] failing samba3 sniff
Created attachment 1102 [details] winxp ethereal sniff for comparison
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
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.
Oh - sorry - that's what the WinXP sniff was. Now I understand - thanks. I have the info I need now - thanks. Jeremy.
Created attachment 1103 [details] Patch part 1. First patch for this problem. Jeremy.
Created attachment 1104 [details] Patch part 2 The combination of these two fix the problem I think... Jeremy.
I've checked these two fixes into SVN. I think this fixes the problem. Please test. Jeremy.
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
Yes, please open a new bug and attach the traces. I'll close this one out now. Thanks, Jeremy.
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
Cause the Win98 FoxPro issue is still unresolved, the bug should be reviewed again. Alex wants to add some notes and another ethereal sniff.
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.
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.
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.
Closing this "dual" bug out. Any more - please log a new bug :-). Jeremy.
Problem still exists on 3.0.14pre1-SVN-build-6092. I've opened new BUG #2551
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.