Bug 3226 - OS/2 extended attributes - the always passed "fEA" flag is completely ignored
OS/2 extended attributes - the always passed "fEA" flag is completely ignored
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
Other OS/2
: P3 normal
: none
Assigned To: Jeremy Allison
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2005-10-29 21:15 UTC by Guenter Kukkukk
Modified: 2009-09-17 15:38 UTC (History)
1 user (show)

See Also:

Failing samba3 on setea/getea - the EA flag is ignored and the returned EA name is not passed in UPPERCASE (2.28 KB, application/octet-stream)
2005-11-02 20:33 UTC, Guenter Kukkukk
no flags Details
Against w2k all this stuff is working fine (2.89 KB, application/octet-stream)
2005-11-02 20:36 UTC, Guenter Kukkukk
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guenter Kukkukk 2005-10-29 21:15:23 UTC
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. */ 
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, 
ea_list->ea.value.length, 0); 
			} else { 
				DEBUG(10,("set_ea: setting ea name %s on file 
					unix_ea_name, fname)); 
				ret = SMB_VFS_SETXATTR(conn, fname, 
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 
	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
Comment 1 Jeremy Allison 2005-10-31 18:28:12 UTC
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.
Comment 2 Guenter Kukkukk 2005-11-01 20:11:15 UTC
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

Comment 3 Jeremy Allison 2005-11-01 22:34:31 UTC
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.

Comment 4 Guenter Kukkukk 2005-11-02 20:30:00 UTC
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 
>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 
Comment 5 Guenter Kukkukk 2005-11-02 20:33:26 UTC
Created attachment 1559 [details]
Failing samba3 on setea/getea - the EA flag is ignored and the returned EA name is not passed in UPPERCASE
Comment 6 Guenter Kukkukk 2005-11-02 20:36:08 UTC
Created attachment 1560 [details]
Against w2k all this stuff is working fine
Comment 7 Jeremy Allison 2005-11-02 23:22:22 UTC
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 ?