[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