[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-970-gd6270df
Stefan (metze) Metzmacher
metze at samba.org
Thu Aug 20 03:45:35 MDT 2009
Jeremy Allison schrieb:
> On Thu, Aug 13, 2009 at 01:10:16PM -0700, Jeremy Allison wrote:
>> I just did :-).
>>
>> " * Extended attributes are stored directly in inodes (on file systems with
>> * inodes bigger than 128 bytes) and on additional disk blocks. The i_file_acl
>> * field contains the block number if an inode uses an additional block. All
>> * attributes must fit in the inode and one additional block."
>
> Ok, I've been thinking about this. If we're going to move
> all extra meta-data into one EA (other than SD's) we need
> to use the user.DOSATTRIB EA name. The reason for this
> is backwards compatibility.
>
> Currently user.DOSATTRIB consists of a string containing
> the dos attributes. 3.5 could maintain this, but then
> after the string store an ndr linearized version of the
> extra metadata (timestamps, allocation etc.) as a blob
> after the string. Existing versions of Samba still work
> by simply parsing the string. 3.5 and above will detect
> the extra blob presence by checking the size of the EA
> is larger than the string and then accessing the blob.
>
> We can't suddenly start to store the DOS attributes
> in a different EA name as then the stored data in the
> filesystem will be incompatible if someone runs
> a previous version of Samba, something we've managed
> to avoid with filesystem data up until now.
>
> We need to make this decision NOW, as once a version
> ships that uses a new EA store name for metadata, we're
> forced to keep this moving forwards for backwards compatibility
> reasons.
>
> The current code has one advantage in that is allows
> vendors who already have full Windows timestamps
> in their (custom?) filesystem to leave the storage
> of create timestamps turned off, only people running
> on top of POSIX with EA's need turn it on. Plus this
> code is already written, tested and is quite a small
> change :-).
>
> How expensive is it to use another EA ? Knowing
> the answer to this would help in making the decision
> on whether I have to change the create timestamp
> store code asap, or if we can leave it as "done".
>
> Comments and thoughts ?
I created some idl based code to parse old and new
style blobs:
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-xattr-01
bin/ndrdump xattr xattr_parse_DOSATTRIB in dosattribFFFF.blob -d 1
--dump-data --validate
pull returned NT_STATUS_OK
3 bytes consumed
[0000] 30 78 34 0x4
xattr_parse_DOSATTRIB: struct xattr_parse_DOSATTRIB
in: struct xattr_parse_DOSATTRIB
x: struct xattr_DOSATTRIB
attrib_hex : '0x4'
version : 0xffff (65535)
info : union xattr_DosInfo(case 65535)
compatinfoFFFF: struct xattr_DosInfoFFFFCompat
attrib : 0x00000004 (4)
push returned NT_STATUS_OK
4 bytes generated (validate)
[0000] 30 78 34 00 0x4.
pull returned NT_STATUS_OK
xattr_parse_DOSATTRIB: struct xattr_parse_DOSATTRIB
in: struct xattr_parse_DOSATTRIB
x: struct xattr_DOSATTRIB
attrib_hex : '0x4'
version : 0xffff (65535)
info : union xattr_DosInfo(case 65535)
compatinfoFFFF: struct xattr_DosInfoFFFFCompat
attrib : 0x00000004 (4)
WARNING! orig bytes:3 validated pushed bytes:4
WARNING! orig pulled bytes:3 validated pulled bytes:4
dump OK
Here you see that we parse the hex string fine without termination,
but would push it with termination (as we never push this compat
info level 0xFFFF and only read it, I think it's fine:.
And this would be the new format I'd propose that we use in s3 and s4
(we can extent it to store more).
The important thing is that the parser autogenerates the leading hex
string from the attrib member and that we have the valid_flags mask
to indicate with members are valid.
metze at SERNOX:~/devel/samba/4.0/master4-test/source4$ bin/ndrdump xattr
xattr_parse_DOSATTRIB in dosattrib3.blob -d 1 --dump-data --validate
pull returned NT_STATUS_OK
56 bytes consumed
[0000] 30 78 34 35 00 00 03 00 03 00 00 00 2F 00 00 00 0x45.... ..../...
[0010] 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E....... ........
[0020] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
[0030] 00 00 00 00 00 00 00 00 ........
xattr_parse_DOSATTRIB: struct xattr_parse_DOSATTRIB
in: struct xattr_parse_DOSATTRIB
x: struct xattr_DOSATTRIB
attrib_hex : '0x45'
version : 0x0003 (3)
info : union xattr_DosInfo(case 3)
info3: struct xattr_DosInfo3
valid_flags : 0x0000002f (47)
1: XATTR_DOSINFO_ATTRIB
1: XATTR_DOSINFO_EA_SIZE
1: XATTR_DOSINFO_SIZE
1: XATTR_DOSINFO_ALLOC_SIZE
0: XATTR_DOSINFO_CREATE_TIME
1: XATTR_DOSINFO_CHANGE_TIME
attrib : 0x00000045 (69)
ea_size : 0x00000000 (0)
size : 0x0000000000000000 (0)
alloc_size : 0x0000000000000000 (0)
create_time : NTTIME(0)
change_time : NTTIME(0)
push returned NT_STATUS_OK
56 bytes generated (validate)
[0000] 30 78 34 35 00 00 03 00 03 00 00 00 2F 00 00 00 0x45.... ..../...
[0010] 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E....... ........
[0020] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
[0030] 00 00 00 00 00 00 00 00 ........
pull returned NT_STATUS_OK
xattr_parse_DOSATTRIB: struct xattr_parse_DOSATTRIB
in: struct xattr_parse_DOSATTRIB
x: struct xattr_DOSATTRIB
attrib_hex : '0x45'
version : 0x0003 (3)
info : union xattr_DosInfo(case 3)
info3: struct xattr_DosInfo3
valid_flags : 0x0000002f (47)
1: XATTR_DOSINFO_ATTRIB
1: XATTR_DOSINFO_EA_SIZE
1: XATTR_DOSINFO_SIZE
1: XATTR_DOSINFO_ALLOC_SIZE
0: XATTR_DOSINFO_CREATE_TIME
1: XATTR_DOSINFO_CHANGE_TIME
attrib : 0x00000045 (69)
ea_size : 0x00000000 (0)
size : 0x0000000000000000 (0)
alloc_size : 0x0000000000000000 (0)
create_time : NTTIME(0)
change_time : NTTIME(0)
dump OK
metze
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090820/7f3c4dd7/attachment.pgp>
More information about the samba-technical
mailing list