samba | s3:libsmb: parse_finfo_id_both_directory_info capture FileID in SMB2_FIND_ID_BOTH_DIRECTORY_INFO response (!199)

[Jeremy Allison]

On Thu, Jan 17, 2019 at 08:45:43AM +0000, Puran Chand wrote:
> New Merge Request !199
> 
> https://gitlab.com/samba-team/samba/merge_requests/199
> 
> Project:Branches: puran157/samba:smbc_readdirplus to samba-team/samba:master
> Author:    Puran Chand
> Assignee:  
> 
> 
> s3:libsmb: parse_finfo_id_both_directory_info capture FileID in SMB2_FIND_ID_BOTH_DIRECTORY_INFO response
> 
> This captures the FileID in struct file_info while parsing SMB2_FIND_ID_BOTH_DIRECTORY_INFO
> response
> 
> Refered MS doc for spec:- https://msdn.microsoft.com/en-us/library/cc246290.aspx
> 
> Signed-off-by: Puran Chand <pchand at vmware.com>

Hmmm. OK, been looking at this closer, and I think I was not right
in my initial NAK. For SMB1 the only way to get the ino information
in SMB1 is to change the trans2 call to use SMB_FIND_ID_BOTH_DIRECTORY_INFO
instead of SMB_FIND_FILE_BOTH_DIRECTORY_INFO.

As SMB1 is dead/dying I'm not sure we need to do this work. If we define
returning 0 for finfo->ino as being "value not fetched" (which is what
the current gvfs caller does for uid/gid values) then your patch is good to go.

The gvfs (or other callers) can check the returned finfo->ino field
and if it's zero then fall back to doing the old libsmb_stat() call
to get that info if needed. That way we're no worse than we were with
SMB1, and significantly faster with SMB2.

Jeremy.