samba | s3:libsmb: parse_finfo_id_both_directory_info capture FileID in SMB2_FIND_ID_BOTH_DIRECTORY_INFO response (!199)
jra at samba.org
Thu Jan 17 22:29:40 UTC 2019
On Thu, Jan 17, 2019 at 08:45:43AM +0000, Puran Chand wrote:
> New Merge Request !199
> Project:Branches: puran157/samba:smbc_readdirplus to samba-team/samba:master
> Author: Puran Chand
> 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
> 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.
More information about the samba-technical