[linux-cifs-client] Re: endianness of uniqueid value in FILE_UNIX_BASIC_INFO

Steve French (smfltc) smfltc at us.ibm.com
Mon Mar 30 17:10:03 GMT 2009


Jeff Layton wrote:
> On Sun, 29 Mar 2009 22:37:59 -0500
> "Steve French (smfltc)" <smfltc at us.ibm.com> wrote:
>
>   
>>>> Is the UniqueID field in FILE_UNIX_BASIC_INFO supposed to little endian
>>>> when it goes over the wire?
>>>>         
>>> yes, the unix extensions use the same wire encoding as the rest of the protocol
>>>       
>> We intentionally treat the file of the UniqueId field as "opaque to the client" as we do with various other values in cifs structures.   We don't want to do unnecessary endian conversion of values that have no meaning to the client (and of course u8 fields do not get converted).  Obviously various fields that contain flags, lengths, sizes, times etc. do have to get converted on the client but there seems no point to convert server generated values that are "random" from the client's perspective and are not parsed by the client.
>>
>>     
>
> The case I was thinking of was 2 clients with different endianness and
> you want to compare st_ino values on them. I'm hard pressed to consider
> an example of an app where this would be important, but I think there's
> value in being consistent here.
>
> On a similar note...
>
> Is it reliable to treat the uniqueid as unique over an entire share?
> The SNIA spec says that it's supposed to be. I gave this a quick look
> in the samba code as well and it appears to be generated using st_dev
> and st_ino, but it would be good to confirm.
>
> The reason I'm asking is that I'm looking at cleaning up the way CIFS
> handles hardlinks...
>   
OK - your example (comparing inode numbers between different client, 
perhaps in backup/archive tools) makes sense, and is sufficient 
justification to make the change (the performance impact of this is not 
bad, but for the alternate case, for non-serverino your other suggestion 
of changing to iunique perhaps would be too big a performance hit - 
don't know ... need more data on the iunique impact).  We should also 
add code to cifs to recognize changes in st_dev on directory lookup (and 
do implicit mounts) because inode number is not necessarily unique as we 
cross devices traversing a long path.

With the change to inode number endianness in this path, I would also 
like to switch the default to "serverino" for Windows


More information about the linux-cifs-client mailing list