[Samba] More on the archive bit saga
Aaron Kincer
kincera at gmail.com
Tue Sep 12 22:05:17 GMT 2006
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
>
>
>
More information about the samba
mailing list