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.
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.
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.
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.
(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.
(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
(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.
Created attachment 650 [details] Implement info level 3 for trans2findfirst/next the way samba 2.x did it
*** Bug 872 has been marked as a duplicate of this bug. ***
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.
If you want to test the current code, please check out the SAMBA_3_0 svn tree. Jeremy.
(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
I'm not sure of the relation between this and bug 872, but bug 872 is not fixed.
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.
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.
(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!
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.