vfs_ea_tdb

[tridge at samba.org]

Volker,

 > It uses a different format than Samba4 does: I don't think
 > that we will have so many EAs that the performance benefit
 > form not fetching always all EAs outweighs the added
 > complexity to maintain the list of EAs manually.

I think you may have misunderstood the Samba4 format. Both your
proposed format and the Samba4 format store all EAs as a single
blob. The difference in the IDL is very small.

To make your code compatible with the Samba4 format, you need to do this:

 1) change the IDL from this:

       typedef [public] struct {
               uint32 num_attributes;
               tdb_attribute attributes[num_attributes];
       } tdb_attributes;

    to this:

       typedef [public] struct {
	       uint16 num_attributes;
	       [size_is(num_attributes)] tdb_attribute *attributes;
       } tdb_attributes;

    I doubt we will use more than 64k EAs per file, so I don't think
    the uint16 will hurt.

 2) use the same key. Both your patch and Samba4 use the device and
 inode number. Your patch uses push_file_id_16() which uses this:

	SIVAL(buf,  0, id->devid&0xFFFFFFFF);
	SIVAL(buf,  4, id->devid>>32);
	SIVAL(buf,  8, id->inode&0xFFFFFFFF);
	SIVAL(buf, 12, id->inode>>32);

  whereas Samba4 uses this:

	SBVAL(key->dptr, 0, st.st_dev);
	SBVAL(key->dptr, 8, st.st_ino);

  that is the same on some platforms, but different on others.

 3) Samba4 also maintains a list of keys of all blobs for a file in
 separate key ".xattr_list". I suspect this is what confused you. This
 is not used to store separate EAs in separate records, it is used to
 allow this tdb to store different types of blobs as well - for
 example Samba4 can use the xattr tdb to store NT ACLs, streams,
 timestamps, dos attributes etc. This list allows Samba4 to clean all
 these up when we unlink a file.
             
So could you please consider using the same format? They really are
extremely similar, and being able to migrate from one code base to the
other while maintaining user data is a huge advantage.

Cheers, Tridge