Hi Bill, Thank you for the quick answer! I have a few comments/questions below.
On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote:
Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing.
Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception?
I will continue my investigation into the details on the differences between the base & pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents.
If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?).
Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS- CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx) .
I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the same session would have succeeded. -Tim _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
