Hello Jeremy, every single OS/2 EA send across the smb wire, contains an EA "flags" (uint8) member. On the OS/2 side, this EA flag can bet set as - 0x00 not a critical EA - 0x80 critical EA The IBM docu says something like this.... "If a source dir or file is containing at least one critical flagged EA, that object(s) should never be copied to a destination file system, which does not support EAs". (A critical EA is one - when missing - the OS or application would not work anymore!) So - if samba is configured to support EAs, files /dirs with that flag set "critical" should be easily handled. But - that flag is currently completely ignored in samba! ---------- Again some background, to shed some light into this: OS/2 uses some simple offset based linked list for all EAs: typedef struct _FEA2LIST { ULONG cbList; /* Total bytes of structure including full list. */ FEA2 list[1]; /* Variable-length FEA2 structures. */ } FEA2LIST; Samba is using a double linked list: struct ea_list { struct ea_list *next, *prev; struct ea_struct ea; }; But both have to fill in some EA data, anchient OS/2 does it this way: typedef struct _FEA2 { ULONG oNextEntryOffset; /* Offset to next entry. */ BYTE fEA; /* Extended attributes flag. */ /* 0 (not critical EA) or FEA_NEEDEA */ BYTE cbName; /* Length of szName, not including NULL. */ USHORT cbValue; /* Value length. */ CHAR szName[1]; /* Extended attribute name. */ } FEA2; Samba uses a different approach, where the DATA_BLOB contains the length and the pointer to the EA raw data: struct ea_struct { uint8 flags; char *name; DATA_BLOB value; }; The OS/2 struct member "fEA" matches the samba "flags" member. And - all of that is passed "across the smb wire"! But - samba completely _ignores_ its own "flags" member ... -------------------------------------- When setting EAs to be stored onto the local samba filesystem: In trans2.c -> function NTSTATUS set_ea() the "flags" parameter is _not_ passed to be stored anyway! (it is only raw EA stuff, but _no_ flags info stored..) ... if (fsp && (fsp->fh->fd != -1)) { DEBUG(10,("set_ea: setting ea name %s on file %s by file descriptor.\n", unix_ea_name, fsp->fsp_name)); ret = SMB_VFS_FSETXATTR(fsp, fsp->fh->fd, unix_ea_name, ea_list->ea.value.data, ea_list->ea.value.length, 0); } else { DEBUG(10,("set_ea: setting ea name %s on file %s.\n", unix_ea_name, fname)); ret = SMB_VFS_SETXATTR(conn, fname, unix_ea_name, ea_list->ea.value.data, ea_list->ea.value.length, 0); } ------------------ When EAs have to be passed back, the statement pea->flags = 0; shows the lack of being not stored anywhere: in trans2.c -> function static BOOL get_ea_value()... ... DEBUG(10,("get_ea_value: EA %s is of length %u: ", ea_name, (unsigned int)sizeret)); dump_data(10, val, sizeret); pea->flags = 0; !!! That is wrong, but it was not _stored_ anyway !! ----------------- So - there is a need to store 1 byte more ("flags") onto the local *nix file systems EAs, to be able to restore them later. To do so, would definitely _break_ any former stored EAs. I think - if that is being implemented, there _must_ be a notice in the release notes about that. I guess, in reality, such an addition would not break too many OS/2 boxes - cause EAs have not been working pretty well in the past. Huh - that is all for now. Anyway - feel free to contact me. :-) Guenter Kukkukk btw - about 1 year ago, tridge and me were _not_ hitting that glitch, when we tried "to put in all the OS/2 EAs stuff into samba4" :-( ... so this glitch is in samba4, too
Ok - how many applications do you know that depend on this ? I don't want to change the on-disk storage format of OS/2 EA's. As this is only one bit of information per EA there are much easier ways to store this. For example, as OS/2 EA names are case insensitive we store "critical" EA's with names in all caps, "normal" EA's with names in lower/mixed case. That would fix the problem without changing the on-disk format. Let me know what apps break without support for this first though. Jeremy.
Hello Jeremy, i cannot report on _any_ application, which is doing that "critical" EAs flags setting! In the past - my OS/2 boxes have only been used for development. I even have no tool, which would report the critical EAflag set - on _all_ my OS/2 boxes! But - there are 10 thousands of OS/2 apps still running ... (I really can't tell, if that "critical" EA flag has ever been used...) Hmm - to not change the "binary EA format on disk" ... and use "that simple bit" inside the EA name, could be a solution!??? But - there is another glitch in samba3 (samba4, too) - which needs some further attention - and is related to this one, so needs some attention - (on OS/2, and windows) - when you set an EA name "MixedCase" - and later-on QUERY that name - you can use _any_ case ("MIXedCaSE") to match the EA name! - BUT, OS/2 and windows _always_ RETURN the EA name in UPPERCASE (not implemented in samba so far) So - samba is free to (locally) store the EA name "in any mixed case" - but should _return_ the EA name in upper case! In the past - samba was storing the EA name "as passed from the client" (adding "user." of course). To not violate former stored EAs, how can the _NEW_ "critical" bit now be stored inside some info in the EA name? I guess - no 100% chance! But some heuristics guess - if an application was _assuming_, to get _all_ EA names back in uppercase, it would have set them also in UPPERCASE - and samba has STORED them in uppercase! Hmm - so samba could store "critical" EA names in "all lower case" - or some internal mixture. But, if the eaname is "A", what can you mix? That is not 100% perfect - but I guess, it will be sane in most cases. .... but it still is a hack! Feel free to contact me. Guenter Kukkukk
Ok, then it's really simple. We always return EA names in uppercase, and for "critical" EA's we could store as uppercase, for non critical EA's we store as lowercase. EA's stored from UNIX will usually be in lowercase, so they'll be returned as non-critical. Actually, if you doubt that "critical" EA's have ever been used in an application I doubt we need to do anything. I have had an IBM internal user (who is a very large user of OS/2 clients and so EA's) tell me that with 3.0.20 all their OS/2 clients work perfectly with Samba. I'm inclined to mark this as "wontfix" unless you can show me an application that fails unless we implement this. I'm guessing it was added to the EA spec but never used. Jeremy.
Hello Jeremy, of course, it is up to you, to decide, that this one will be flagged as "wontfix"... Then you simply "have 2 cadavers in the closet" - to be realized in any further bug report! The "critical" bit might be useless - I'm not the "Bank of Brasilia", which is said ... to still use many thousands of of OS/2 clients. (???) But - returning EA names in UPPERCASE, should be simple to implement! >Actually, if you doubt that "critical" EA's have ever been used in an >application I doubt we need to do anything. I have had an IBM internal user (who >is a very large user of OS/2 clients and so EA's) tell me that with 3.0.20 all >their OS/2 clients work perfectly with Samba. ... "work perfectly with Samba" ... ? you are kidding - or that (OS/2) user is maintaining a network, where no or only small EAs are in use! (and more...) See still unfinished bug #3212 - should I send you screenshots, so you can pass them over to "your corporate user"? :-)) I will send 2 more sniffs - which do expose, that samba3 is ignoring the EAs flags, and does _not_ return EA names in uppercase! (as you can see - MS windows is doing a better job .. which you are hunting..) It really do not intend to distract you from your great samba work. :-) ... only my 2 cents ... Cheers - Guenter
Created attachment 1559 [details] Failing samba3 on setea/getea - the EA flag is ignored and the returned EA name is not passed in UPPERCASE
Created attachment 1560 [details] Against w2k all this stuff is working fine
Bug #3212 is finished as far as I can see. It's a no-op and we implement that correctly now. What application exactly fails when Samba returns a lower case EA name ? Yes, I know it's not what Windows does (and I can and will easily fix this) but what does OS/2 do with a lower case EA name that causes an application failure ? The only outstanding application visible OS/2 bugs I know about are the one with secondary trans2 calls (can't remember the bugid here, sorry). It isn't a problem ignoring the EA flag if no application uses it. I ask again, what application do you have that fails because we don't implement this flag ? Jeremy.