다음을 통해 공유

3.2.5.16 Receiving an SMB_COM_READ_RAW Response

  • 아티클

The SMB_COM_READ_RAW response is a transfer of raw bytes from the server to the client. There is no SMB header, parameter block, or data block. Therefore, the SMB_COM_READ_RAW response MUST NOT be processed as specified in section 3.2.5.1. Instead, the client MUST query the SMB transport to determine the number of bytes received:

  • If the request was made to read from a regular file and the number of bytes received is less than the number requested, then the end of file has been reached.

  • If the number of bytes returned is zero, then the read began at or beyond the end of file (for a regular file) or an error occurred.

It is possible that an OpLock break event on the server can cause the server to send an OpLock Break Notification request to the client at approximately the same time that the client sends an SMB_COM_READ_RAW request. If this happens, the OpLock Break Notification request can arrive before the Raw Read response from the server. In order to avoid confusing the OpLock break with the Raw Read response, the client MUST perform the following tests:

  • If the client currently holds an OpLock on an open file on the server, and

  • If the message received is the size of an OpLock Break Notification request (51 bytes), and

  • If the first four bytes of the data received are equal to '\x0', 'S', 'M', 'B', and

  • If the fifth byte in the data received is equal to the value of SMB_COM_LOCKING_ANDX (0x24), and

  • If the value at the correct offsets for MID is 0xFFFF ((USHORT)(-1)), then

The likelihood that the message received is an OpLock Break Notification request is very high. The client MAY apply these further tests to minimize the chance of a false positive:

  • The SMB_FLAGS_REPLY bit in an OpLock break MUST be clear in the appropriate location for the SMB_Header.Flags field.

  • The NumberOfRequestedUnlocks and NumberOfRequestedLocks fields MUST both be zero in an OpLock break.

If these conditions are met, the client MUST perform as if it has received an OpLock Break Notification and MUST process the message accordingly. The server, having received the Raw Read request while an OpLock break is still outstanding, responds to the Raw Read request by sending a zero-length response.

After responding to the OpLock break, the client SHOULD use a different READ command to retry the failed Raw Read request.