[Samba] More on the archive bit saga

[Aaron Kincer]

I appreciate the help.

I've got those set (ea support I didn't have) and everything appears to 
work fine except for MS Word. Notepad, Wordpad, OpenOffice.org, MS Excel 
and even MS Paint seem to have no problem setting the archive bit. Word 
is the problem child. This would seem on the surface to indicate maybe 
there is something strange with Word. Google reveals past inquiries into 
this to the list. Has anyone found a solution?

Thanks,

Aaron Kincer

Guenter Kukkukk wrote:
>> Using attrib -s on the file removed the "access denied" part. Strange
>> that some files mysteriously got ACLs when others did not.
>>
>> Yes, map system = no is set.
>>
>> server:/share/personal/smith# getfattr -d foo.txt
>> # file: foo.txt
>> user.DOSATTRIB="0x0"
>>
>> Is that good or bad?
>>     
>
> Hi Aaron,
>
> assuming the following conditions are met:
> - the samba share is located on a file system
>   which supports xattr
> - smb.conf has the following entries
>  ea support = yes
>  store dos attributes = yes
>  map archive = no
>  map hidden = no
>  map system = no
>
> Expressing the DOS attribute bits in hexadecimal notation, you get
> the following - the user.DOSATTRIB like display is shown in braces:
> readonly  0x01  (0x1)
> hidden    0x02  (0x2)
> system    0x04  (0x4)
> archive   0x20  (0x20)
>
> Any mixture of no attribute to all attributes set is possible.
> The bits are ORed together.
> So, when all attributes are set: | is the OR operator
> 0x01 | 0x02 | 0x04 | 0x20 results to 0x27
>
> getfattr -d foo.txt
> # file: foo.txt
> user.DOSATTRIB="0x27"
>
> matches the win console output:
> attrib foo.txt
> A  SHR     Z:\foo.txt
>
> When removing all attributes with
> attrib -r -h -s -a foo.txt
>
> windows shows:
> attrib foo.txt
>            Z:\foo.txt
>
> and linux:
> getfattr -d foo.txt
> # file: foo.txt
> user.DOSATTRIB="0x0"
>
> As already noted, any mixture of bits is possible.
> Hope this helps.
> Guenter
>
>
>