none
What is the expected Server behavior if Length=0 in SMB2_LOCK_ELEMENT RRS feed

  • Question

  • Hi

    I am referring to the MS spec but it doesn't specify what should be the server behavior if the Length(8 bytes) is 0.

    Should the whole file be locked starting from the `Offset(8byotes)` like in `fcntl()` or it's just a byte lock ?

    Thursday, July 2, 2020 9:56 AM

Answers

  • Hi Vmittal,

    I checked our sources for the SMB2 protocol itself and, as I expected, and it doesn’t concern itself regarding the Length field.  Instead, it passes the request down to the lower-level file store, which is documented for Microsoft Ihe document [MS-FSA].  At [MS-FSA] 2.1.5.7 “Server requests a byte-range lock” explicitly states that Length may be zero, not that an application doing so makes sense, in my opinion.  However, at [MS-FSA] 2.1.4.10 “Algorithm for determining if a range access conflicts with byte-range locks”, 2.1.5.7 references, includes a special test if both the Offset and Length are zero; if so then there is no conflict.  But if the Offset is non-zero, then it continues.  Notice further that it calculates the first byte and last byte of a range as Offset and (Offset + Length – 1).  If Offset is 10 and length is zero, then the first byte is 10 and the last byte is 9 (10 + 0 – 1).  Your file store may do something different.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, July 16, 2020 6:22 PM
    Moderator

All replies

  • Hi vmittal

    Thank you for your question.  I will research this for you.  Are you actually seeing such traffic or is your question hypothetical? 


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, July 3, 2020 4:32 AM
    Moderator

  • Thank you for your question.  I will research this for you.  Are you actually seeing such traffic or is your question hypothetical? 

    We are implementing CIFS server and this question came along. Have been looking in some open source implementations to understand. But thought of directly asking the experts :)

    Friday, July 3, 2020 9:21 AM
  • Hi Bryan

    Any updates on this ?

    Thank You

    Friday, July 10, 2020 4:32 AM
  • I don't have an update yet, but this is my active issue.  I'm skeptical that an application or client redirector would ever send such a request, but I'm walking our code to see if our server ever checks for zero length and drops the request or if it processes it.  Ultimately, it (SMB2) may just pass it (the request) down to the underlying file store (NTFS and ReFS in Windows) such that this would end up being a file-system behavior and not a protocol behavior.  In Microsoft's world, then, such a thing may be documented in [MS-FSA] and the locking pseudo-code.  I'll check.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, July 10, 2020 6:35 AM
    Moderator
  • Hi Vmittal,

    I checked our sources for the SMB2 protocol itself and, as I expected, and it doesn’t concern itself regarding the Length field.  Instead, it passes the request down to the lower-level file store, which is documented for Microsoft Ihe document [MS-FSA].  At [MS-FSA] 2.1.5.7 “Server requests a byte-range lock” explicitly states that Length may be zero, not that an application doing so makes sense, in my opinion.  However, at [MS-FSA] 2.1.4.10 “Algorithm for determining if a range access conflicts with byte-range locks”, 2.1.5.7 references, includes a special test if both the Offset and Length are zero; if so then there is no conflict.  But if the Offset is non-zero, then it continues.  Notice further that it calculates the first byte and last byte of a range as Offset and (Offset + Length – 1).  If Offset is 10 and length is zero, then the first byte is 10 and the last byte is 9 (10 + 0 – 1).  Your file store may do something different.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, July 16, 2020 6:22 PM
    Moderator
  • But if the Offset is non-zero, then it continues.  Notice further that it calculates the first byte and last byte of a range as Offset and (Offset + Length – 1).  If Offset is 10 and length is zero, then the first byte is 10 and the last byte is 9 (10 + 0 – 1).  Your file store may do something different.

    Hi Bryan

    Thanks for checking this and the detailed answer.

    For the last comment, when first byte is 10 and last byte is 9, what would be the expected behavior ? Is it left for the underlying filesystem to decide ?

    Friday, July 17, 2020 3:34 AM
  • As for Microsoft's file store, the remaining algorithm as described in [MS-FSA] is continued.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, July 17, 2020 3:56 AM
    Moderator
  • From that algorithm, does that mean that specifying a length 0 lock at nth offset will lock the (n-1)th byte, if offset > 0
    • Edited by vmittal Friday, July 17, 2020 4:00 AM
    Friday, July 17, 2020 4:00 AM
  • That sub-algorithm is only to decide if there is a lock conflict (an overlap between the new request and an existing, granted lock).

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, July 17, 2020 5:28 AM
    Moderator
  • Ah, ok !!

    Thank you

    Friday, July 17, 2020 5:44 AM