Bug 1677 - EAs: call_trans2findfirst (info_level 3) returns ERRunknownlevel
Summary: EAs: call_trans2findfirst (info_level 3) returns ERRunknownlevel
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.4
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-28 15:51 UTC by Marcel Müller
Modified: 2005-08-24 10:23 UTC (History)
3 users (show)

See Also:


Attachments
Packet trace (2.10 KB, application/octet-stream)
2004-09-01 09:35 UTC, Frank Giessler
no flags Details
Implement info level 3 for trans2findfirst/next the way samba 2.x did it (1.95 KB, patch)
2004-09-13 07:57 UTC, Frank Giessler
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Müller 2004-08-28 15:51:29 UTC
The function SMB_INFO_QUERY_EAS_FROM_LIST is not supported by
call_trans2findfirst. It is only decoded by call_trans2qfilepathinfo.
This prevents OS/2 and eCS clients (with IBM Peer) from viewing and accessing
any file or folder on a samba share through the PMSHELL. I think this applies to
all 3.x versions of smbd. Tested with 3.0.2 and 3.0.4; the source of 3.0.6 seems
to contain this issue too.
SMB_INFO_QUERY_ALL_EAS seems to be unsupported by call_trans2findfirst too.
Comment 1 Jeremy Allison 2004-08-31 18:14:50 UTC
These are the only findfirst info levels known about by Windows 2003 (from Samba4)

/* trans2 findfirst levels */
/*
w2k3 TRANS2ALIASES:
Checking for FINDFIRST aliases
        Found level    1 (0x001) of size  68 (0x44)
        Found level    2 (0x002) of size  70 (0x46)
        Found level  257 (0x101) of size 108 (0x6c)
        Found level  258 (0x102) of size 116 (0x74)
        Found level  259 (0x103) of size  60 (0x3c)
        Found level  260 (0x104) of size 140 (0x8c)
        Found level  261 (0x105) of size 124 (0x7c)
        Found level  262 (0x106) of size 148 (0x94)
Found 8 levels with success status
Found 0 aliased levels
*/
#define SMB_FIND_STANDARD                   1
#define SMB_FIND_EA_SIZE                    2
#define SMB_FIND_DIRECTORY_INFO         0x101
#define SMB_FIND_FULL_DIRECTORY_INFO    0x102
#define SMB_FIND_NAME_INFO              0x103
#define SMB_FIND_BOTH_DIRECTORY_INFO    0x104
#define SMB_FIND_ID_FULL_DIRECTORY_INFO 0x105
#define SMB_FIND_ID_BOTH_DIRECTORY_INFO 0x106
#define SMB_FIND_UNIX_INFO              0x202

If OS/2 supports levels 3 and 4 as well I need to see either a definition of
what these calls should return on a query either from an OS/2 programming book
or a packet trace showing OS/2 querying and retrieving these info levels in a
findfirst against an OS/2 SMB server.

Jeremy.
Comment 2 Frank Giessler 2004-09-01 01:32:22 UTC
Here are the infolevels supported by OS/2 according to the toolkit:

/************************************************************
EA Info Levels & Find First/Next
=========================================
API's: DosFindFirst, DosQueryFileInfo, DosQueryPathInfo, DosSetFileInfo,
DosSetPathInfo
************************************************************/

/* File info levels&gml All listed API's */
#define FIL_STANDARD           1     /* Info level 1, standard file info */
#define FIL_QUERYEASIZE        2     /* Level 2, return Full EA size */
#define FIL_QUERYEASFROMLIST   3     /* Level 3, return requested EA's */
#define FIL_STANDARDL         11     /* LFS - Info level 11, standard file info
for large files*/
#define FIL_QUERYEASIZEL      12     /* LFS - Level 12, return Full EA size for
large files */
#define FIL_QUERYEASFROMLISTL 13     /* LFS - Level 13, return requested EA's */


/* File info levels: Dos...PathInfo only */
#define FIL_QUERYFULLNAME     5     /* Level 5, return fully qualified
name of file */


Would it not be a good idea to re-implement the behavior of Samba 2.x? I once
tried to do so but srvstr_get_path() set ntstatus to
NT_STATUS_OBJECT_NAME_INVALID because it was checking ".", which for some reason
is considered invalid. After I discarded the bad status it was working pretty
well. I can hack this again and send a diff (and/or a level-10 log) if it is
going to help.
Comment 3 Frank Giessler 2004-09-01 09:35:30 UTC
Created attachment 633 [details]
Packet trace

This is a tcpdump between an OS/2 and a WinXP workstation showing the "Query
EAs From List" level of interest. XP handles it well, so I find it surprising
that Win2003 shouldn't know anything about it.
Comment 4 Marcel Müller 2004-09-02 03:04:13 UTC
(In reply to comment #1)
> These are the only findfirst info levels known about by Windows 2003 (from Samba4)

> If OS/2 supports levels 3 and 4 as well I need to see either a definition of
> what these calls should return on a query either from an OS/2 programming book
> or a packet trace showing OS/2 querying and retrieving these info levels in a
> findfirst against an OS/2 SMB server.

SMB_INFO_QUERY_EAS_FROM_LIST is already supported by call_trans2qfilepathinfo.
I think this is the same but in conjunction with find_first/find_next.
Comment 5 thomas schönemann 2004-09-13 05:39:19 UTC
(In reply to comment #2)
> Would it not be a good idea to re-implement the behavior of Samba 2.x? I once
> tried to do so but srvstr_get_path() set ntstatus to
> NT_STATUS_OBJECT_NAME_INVALID because it was checking ".", which for some reason
> is considered invalid. After I discarded the bad status it was working pretty
> well. I can hack this again and send a diff (and/or a level-10 log) if it is
> going to help.

hello frank,
would it be possible for you to send me your changes please?
we are very busy here at the moment to migrate our file services from SUN
pc-netlink (under solaris) to samba 3 (solaris).  
Cause we need to serve about 220 os/2 clients i encountered this major problem too 
and i want to fix it !

thomas
 

Comment 6 Frank Giessler 2004-09-13 07:52:27 UTC
(In reply to comment #5)
> hello frank,
> would it be possible for you to send me your changes please?

Okay, here we go. But please remember: this is not complete and (very likely)
not even correct. It should be used as a starting point only. All I can say is
that it seems to work.
Comment 7 Frank Giessler 2004-09-13 07:57:51 UTC
Created attachment 650 [details]
Implement info level 3 for trans2findfirst/next the way samba 2.x did it
Comment 8 Steve Wendt (mail bounces back 2005-04-04 10:13:48 UTC
*** Bug 872 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Allison 2005-04-04 10:23:47 UTC
This code has been completely rewritten and OS/2 EA's will be fully supported
(including this call) in Samba 3.0.15.

Thanks,

Jeremy.
Comment 10 Jeremy Allison 2005-04-04 10:24:13 UTC
If you want to test the current code, please check out the SAMBA_3_0 svn tree.
Jeremy.
Comment 11 thomas schönemann 2005-04-05 00:11:25 UTC
(In reply to comment #10)
> If you want to test the current code, please check out the SAMBA_3_0 svn tree.
> Jeremy.
> 

i will try to do that this afternoon/evening.
await my results tomorrow!

thomas
Comment 12 Steve Wendt (mail bounces back 2005-04-19 16:32:43 UTC
I'm not sure of the relation between this and bug 872, but bug 872 is not fixed.
Comment 13 Steve Wendt (mail bounces back 2005-04-19 16:38:09 UTC
Copying a file on the command line gives the following message (3.0.15 pre2):

The extended attributes for the file or directory were
discarded because the target file system does not support them.
Comment 14 Jeremy Allison 2005-04-19 19:04:08 UTC
Are you running on a filesystem that can store EA's ? You require a server
filesystem that will support them before OS/2 will work correctly.
Jeremy.
Comment 15 Steve Wendt (mail bounces back 2005-04-20 10:44:27 UTC
(In reply to comment #14)
> Are you running on a filesystem that can store EA's ? You require a server
> filesystem that will support them before OS/2 will work correctly.

Ah, I had not thought of that.  I think that explains the problem, thanks!
Comment 16 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:23:07 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.