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

[Jeff Layton]

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...

-- 
Jeff Layton <jlayton at redhat.com>