Bug 2541 - copy of file(s) from samba share to an OS/2 local drive is failing
Summary: copy of file(s) from samba share to an OS/2 local drive is failing
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.12
Hardware: All OS/2
: P3 critical
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-03-24 00:09 UTC by Guenter Kukkukk
Modified: 2005-08-24 10:16 UTC (History)
0 users

See Also:

failing samba3 copy case (7.18 KB, application/octet-stream)
2005-03-24 00:10 UTC, Guenter Kukkukk
no flags Details
working winxp copy case (87.79 KB, application/octet-stream)
2005-03-24 00:12 UTC, Guenter Kukkukk
no flags Details
Running FOX Pro from Samba drive Windows'98 (9.53 KB, application/octet-stream)
2005-03-24 00:52 UTC, Alex Masterov
no flags Details
NEW - failing samba3 ethereal sniff with NegProt (4.44 KB, application/octet-stream)
2005-03-24 21:40 UTC, Guenter Kukkukk
no flags Details
NEW - same ethereal sniff, when copy winxp to os2 (with NegProt) (6.87 KB, application/octet-stream)
2005-03-24 21:51 UTC, Guenter Kukkukk
no flags Details
Proposed patch. (1018 bytes, patch)
2005-03-25 17:42 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-24 00:09:05 UTC
Hello to the samba developers,

this bug has been tested on svn build Version 3.0.14pre1-SVN-build-6016.
Copying 1 (or more files) from a samba share to a local OS/2
drive is failing, when the shell 4os2.exe is used inside an OS/2
text commandline window. The file does not contain any extended attributes.

Two SMB shares have been "mounted":
   net use k: \\linux200\testgk      samba3 share
   net use w: \\winxp1\samba         windowsXP-ProSP2 share

The same file "client.c" is copied from samba and from winxp to a
local drive:

[f:\samba3 2]copy k:client.c .
K:\samba3\client.c => F:\samba3\client.c
The parameter is incorrect.
     0 files copied

[f:\samba3 0]copy w:client.c .
W:\test\client.c => F:\samba3\client.c
     1 file copied

I have sniffed both copy operations and will attach them.

Best wishes.
Comment 1 Guenter Kukkukk 2005-03-24 00:10:06 UTC
Created attachment 1105 [details]
failing samba3 copy case
Comment 2 Guenter Kukkukk 2005-03-24 00:12:00 UTC
Created attachment 1106 [details]
working winxp copy case
Comment 3 Alex Masterov 2005-03-24 00:52:26 UTC
Created attachment 1109 [details]
Running FOX Pro from Samba drive Windows'98

Here is attempt to run FoxPro 2.6 from Samba 3.0.14pre1-SVN-build-6031. 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 4 Guenter Kukkukk 2005-03-24 21:36:48 UTC
Hi Jeremy,

i had time to dig a bit deeper.
The shell 4os2.exe also tries to copy the extended attributes (EAs).
That is failing during QUERY_FILE_INFO -> Info query all EAs.
To shorten the sniffs, i now used a very short textfile (containing
only "huhu").
I also tried another os2 box - a warpserver 5.0. The following is

[<server01>-f:\tmp\samba3]copy y:gk\short.txt .
Y:\gk\short.txt => F:\tmp\samba3\short.txt
SYS0255: The extended-attribute list size is incorrect.
     0 files copied
You'll see the fix, when you compare the winxp sniff.

I attach 2 new sniffs, the os2 sniff also contains the NegProt stuff.
Please have a closer look to the protocol index, which is returned
in the negprot response packet.
The index is 3, but should be 4! (also ethereal's text info is a bit
Have a look into smb_server/negprot.c from samba4. The supported_protocols[]
array should be tuned in samba3.
We had the same problem with negprot in samba4....

Further on, DosErrors should be flagged in FLAGS2 (not NT_STATUS).
Also the FLAGS2_EXTENDED_ATTRIBUTES bit is (often) not returned
the right way. (smb.conf settings are ignored most the time, too).

That's it for now.
Best wishes.
Comment 5 Guenter Kukkukk 2005-03-24 21:40:15 UTC
Created attachment 1117 [details]
NEW - failing samba3 ethereal sniff with NegProt
Comment 6 Guenter Kukkukk 2005-03-24 21:51:56 UTC
Created attachment 1118 [details]
NEW - same ethereal sniff, when copy winxp to os2 (with NegProt)
Comment 7 Jeremy Allison 2005-03-25 17:42:54 UTC
Created attachment 1122 [details]
Proposed patch.

Ok, here is the fix for selecting the wrong negprot value plus the wrong EA
size in the info query. I've applied these to the latest SVN code. The NT
status codes has already been fixed in SVN. I think these should fix this
problem. Please check.
Comment 8 Jeremy Allison 2005-03-25 18:15:21 UTC
I think the patches now in the tree should fix this one. Please re-open if not.
Comment 9 Guenter Kukkukk 2005-03-25 22:45:53 UTC
Hello Jeremy,

i tested again with svn build Version 3.0.14pre1-SVN-build-6016.
The NegProt stuff is okay now. :-)

But the copy bug is still there.

When you look at the WinXP sniff, you'll see, that for
QUERY_FILE_INFO -> Info query all EAs,
_even_ when no EAs can be found, the "EA List Length" parameter
must be returned as 4 (and not 0)! (btw - the file "short.txt" has no EAs)!

The following 1 addition is needed to get that right:
in smb/trans2.c -> static int call_trans2qfilepathinfo()
      /* We have data_size bytes to put EA's into. */
      size_t total_ea_len = 0;

      DEBUG(10,("call_trans2qfilepathinfo: SMB_INFO_QUERY_ALL_EAS\n"));

      ea_ctx = talloc_init("ea_ctx");
      if (!ea_ctx) {

      ea_list = get_ea_list_from_file(ea_ctx, conn, fsp, fname, &total_ea_len);
      if (!ea_list || (total_ea_len > data_size)) {
+       SIVAL(pdata,0,4);   /* EA List Length must be set to 4 */
        data_size = 4;

      data_size = fill_ea_buffer(ea_ctx, pdata, data_size, conn, ea_list);

I made that change locally and rebuild. All tested stuff is ok then.
I checked that for both EA settings in smb.conf:
    ea support = yes
    ea support = no
and for files with and without EAs.

ea_list = get_ea_list_from_file() returns NULL, when "ea support = no",
so that case is also caught here.
I guess, the change you made to fill_ea_buffer() must also be corrected to
but in this case that function is not called anyway.

Best wishes.
Comment 10 Jeremy Allison 2005-03-27 13:43:07 UTC
Yes, you're correct ! Thanks. Applied.
Comment 11 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:16:55 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.