Hi Metze

Thanks for contacting Microsoft Support. We have created a case, 
112101850229631, to track your inquiry and a support engineer will contact you 
to assist further.

Thanks
Tarun Chopra.

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:me...@samba.org] 
Sent: Thursday, October 18, 2012 12:56 AM
To: Interoperability Documentation Help; cifs-protocol@cifs.org; 
p...@tridgell.net
Subject: Scope of a File.LeaseKey on the client

Hi DocHelp,

is it correct that the LeaseKey on a file is shared between different user 
contexts?

>From 3.2.4.3 Application Requests Opening a File:

  [...]

  If the client implements the SMB 2.1 or SMB 3.0 dialect and 
Connection.SupportsFileLeasing is
  TRUE, the client MUST search the GlobalFileTable for an entry matching one of 
the following:

  - The application-supplied PathName if TreeConnect.IsDfsShare is TRUE.
  - The concatenation of Connection.ServerName, TreeConnect.ShareName, and the
    application-supplied PathName, joined with pathname separators
(example: server\share\path),
    if TreeConnect.IsDfsShare is FALSE.

  If an entry is not found, a new File entry MUST be created and added to the 
GlobalFileTable and a
  File.LeaseKey, as specified in section 3.2.1.5, MUST be assigned to the 
entry. File.OpenTable
  MUST be initialized to an empty table and File.LeaseState MUST be initialized 
to
  SMB2_LEASE_NONE.

  [...]

  If the client accesses a file through multiple paths, such as using different 
server names or share
  names or parent directory names, it will create multiple File elements, and 
therefore multiple
  File.LeaseKeys for the same remote file. This loses the performance benefits 
of sharing cache state
  across all Opens of the same file, and may cause additional lease breaks to 
be generated, as
  actions by a client through one path will affect caching by that client 
through other paths. However,
  the impact is a matter of performance; cache correctness is preserved.

  [...]

It seems that the LeaseKey is purely tight to the full path to the file from 
the client perspective.

I guess on a terminal server where multiple users access the same path on the 
server, the LeaseKey is shared between them, is that correct?

If this is true, then this implies that each user sees the same content in a 
file, which might not be true.

E.g. in Samba we allow shares to expose different FSA level directories based 
on user account.
The typical example is the "homes" share which exposes the unix home directory 
of the specific user.

I fear that we have to disable such powerful features if we want to take 
advantage of leases, otherwise the client would treat 
\\sambaserver\homes\commonfile.doc of
user1 and
\\sambaserver\homes\commonfile.doc of user2 as the same file.

I assume user1 and user2 should share the client_guid and lease_key, which 
means data corruption and/or security problems are very likely, if the server 
grants leases in this case.

metze

_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to