Hello Jeremy,

the following is related to samba3 svn rev. 11685.

I know, that some days ago the semantics of "store dos attributes" has
chandeg slightly.

Beside other changes, samba3 now _first_ tries to store dos attributes into
the EA "user.DOSATTRIB". If that fails, a fallback to the former used file 
system bits is done.

I cannot say, whether the latest code changes result in the following glitch,
cause I never did test this before!

SYMPTOM:
When the following is set in smb.conf in the [global] section
  store dos attributes = yes
  ea support = yes
  (and _no_ "map" entry is used)
and the used file system does support xattr.

When copying a new file from OS/2 to a samba3 share (so the file is newly 
created on samba3), linux getfattr shows, that "user.DOSATTRIB" is not created!
The former used file system execute bits and the inverted user 'w' are still
in use. ('chown u-x file.txt' will now remove the Archive bit again).

The source file had only the archive (or readonly) bit set.
(When the System or Hidden bits were already present in the source, then
the EA is always created!)

I was wondering, why this does not happen, when a windows client is used.
Some additional DEBUG() statements in smbd/dosmodes.c and 2 ethereal traces
are showing the following.
In smbd/dosmode.c, function file_set_dosmode() line 372

        if (dos_mode(conn,fname,st) == dosmode)      !!!!!
                return(0);                           !!!!!

        /* Store the DOS attributes in an EA by preference. */
        if (set_ea_dos_attribute(conn, fname, st, dosmode)) {
                return 0;
        }

if (dos_mode(...) == dosmode) was always true with OS/2, but not with windows,
so the following EA setting function was not called!
The interesting thing is, that when the archive bit 0x20 should be set,
OS/2 is passing dosmode == 0x20 and windows (mostly) is passing 0xa0 !!!
So the Bit FILE_ATTRIBUTE_NORMAL (0x80) is additionally set on windows,
it was not defined in the OS/2 days - and should be masked off here also
in samba.
So, if we add the following to dosmode.c: 
        dosmode &= SAMBA_ATTRIBUTES_MASK;     /* !!!!!!! */
        if (dos_mode(conn,fname,st) == dosmode)
                return(0);

OS/2 and windows should behave the same here - and of course, now the
bug can _also_ be seen when using windows!

Jeremy, I leave it up to you, to find the location, which needs some
modification.

Best wishes.
Guenter Kukkukk

PS - my irc talks yesterday where not intended to make you feel unhappy! :-)
I hope, this is helping a bit...
-----
btw - OS/2 is also not masking out "invalid file bits" - here FileCommander/2
was falling into that pitfall:
http://bugs.silk.apana.org.au/show_bug.cgi?id=95
Samba3 is setting FILE_ATTRIBUTE_NORMAL on line 2920 in trans2.c
        if (!mode)
                mode = FILE_ATTRIBUTE_NORMAL;
whithout looking for the used SMB dialect version.
I agree, OS/2 should also mask off the upper bits!
FC/2 was taking the samba3 passed file attributes and passed them over to
DosOpen() for the dest. file - "access denied". Also not bad :-)