On 9/30/22 11:42, Erich E. Hoover wrote:
+/* decode the xattr-stored DOS attributes */ +static int parse_samba_dos_attrib_data( char *data, int len ) +{
- size_t string_len = strnlen( data, len );
- if (len > string_len + 3)
- {
uint16_t version;memcpy( &version, data + string_len + 1, 2 );version = ntohs(version);
Are you sure this is correct? My reading of the code, having taken a longer time to look at it, is that it's basically an NDR format string containing, in order:
* a null-terminated string (for compatibility with the old foramt) * align to 2 bytes * the xattr_DosInfo version * align to 4 bytes * the xattr_DosInfo version, again (because NDR) * the contents of the xattr_DosInfo structure
I'm not a Samba expert and this is difficult to confirm without familiarity with the code, but I don't think that the xattr are actually stored locally as big-endian; probably that's just how they're transmitted over the network. Confer my example from earlier:
whatsit@camazotz:~/vmshare$ attr -q -g DOSATTRIB test-file | xxd -g4 00000000: 00000400 04000000 11000000 21000000 ............!... 00000010: 00000000 00000000 c27bfa02 65c8d801 .........{..e...
The attributes themselves are clearly little-endian, and the version numbers seem to be consistent with alignment rather than endianness switching.
if ( version != 3 ){static BOOL warn = TRUE;if (warn){FIXME( "Unsupported Samba DOSATTRIB Extended Attribute version: %u\n",version );warn = FALSE;}}
We're not handing version 3 either, are we? Note that this seems to be the xattr_DosInfo version, not the Samba version.
- }
- if (string_len > 2 && data[0] == '0' && data[1] == 'x')
- {
data[len] = 0;return strtol( data+2, NULL, 16 ) & XATTR_ATTRIBS_MASK;- }
- return 0;
+}