Partager via

3.3.5.24 Receiving an SMB_COM_READ_RAW Request

  • Article

Upon receipt of an SMB_COM_READ_RAW Request (section 2.2.4.22.1) from the client, the server MUST verify that the Server.Capabilities include CAP_RAW_MODE, and that Connection.IsSigningActive is FALSE (no SMB frame is sent in the response; therefore, this command is not compatible with SMB signing). If those conditions are met, the server MUST also verify the FID and the UID and MUST verify that the user has, at minimum, read permission on the file, named pipe, or device indicated by the FID. If any of these conditions is not met, the server MUST send a zero-length reply over the SMB transport to indicate failure of the request.

The server response to an SMB_COM_READ_RAW request is not a standard SMB response. Instead, the server sends raw data to the client via the underlying transport. The server relies upon the transport to ensure that the data is transferred in sequence; that the entire message is sent contiguously; that transmission errors are detected; and that the number of bytes transferred is reported to the receiving client.

Because there is no SMB Header (section 2.2.3.1) included in the response, there is no mechanism for reporting specific errors. If an error occurs, the server MUST send a zero-length response to the client via the SMB transport. A zero-length reply can also indicate that the requested offset is at or beyond end of file (EOF) and that no bytes are available to be returned. The client can then use a different SMB command to perform a Read. The alternate Read request either fails, providing the client with an actionable status code, or it succeeds, allowing the client to read the data that it had originally attempted to read.

If the server receives an SMB_COM_READ_RAW request after having sent an OpLock Break Notification to the client and is actively waiting for the client's response to the OpLock Break Notification, the server MUST send a zero-length reply. The server might then re-issue the OpLock Break Notification. This is done because the OpLock Break Notification sent by the server can arrive at the client after the client has issued the SMB_COM_READ_RAW request. In this situation, the client could mistake the OpLock Break Notification request for the Raw Read response. See Receiving Any OpLock Break Notification (section 3.2.5.42) for steps that the client MUST take to handle this situation.

If there are no errors and the FID indicates a regular file, processing is as follows:

  • The server MUST attempt to read from the underlying object store for the file indicated by the FID in the response. It MUST start reading from the file at the offset indicated by the Offset field in the request, or by the combination of Offset and OffsetHigh if CAP_LARGE_FILES was negotiated. The client MUST read MaxCountOfBytesToReturn bytes or until EOF, whichever comes first.<275>

  • If the offset is at or beyond EOF, the server MUST send a zero-length message to the client via the SMB transport.

  • If the client requests to read more bytes than the file contains, or to read beyond EOF, the number of bytes returned by the server message MUST be the number of bytes actually read from the file. A response message containing fewer bytes than were requested from a regular file indicates that EOF was encountered.

If there are no errors, and the FID indicates a named pipe or device, the following additional processing applies:

  • The offset value is used only if it is relevant to the object from which the data is read.

  • If the Timeout value is -1 (0xFFFFFFFF, "wait forever") or the server does not implement Timeout processing,<276> the server SHOULD wait until there are at least MinCountOfBytesToReturn bytes of data read from the device before returning a response to the client.

  • If the Timeout value is -2 (0xFFFFFFFE, "default"), the server SHOULD wait for the default time-out associated with the named pipe or I/O device.

  • If the Timeout value is zero and no data is currently available, the server SHOULD send a successful response with the DataLength field set to zero.

  • Otherwise, the server SHOULD wait to send the response until either MinCountOfBytesToReturn or more bytes of data become available or the Timeout in milliseconds elapses. If Timeout elapses before MinCountOfBytesToReturn bytes are read, the server SHOULD send a response with an error status indicating that the Timeout occurred and SHOULD also respond with any bytes already read.

The server MUST NOT respond as specified in section 3.3.4.1. The server MUST add the total number of bytes in the message to the Server.Statistics.sts0_bytessent_low and Server.Statistics.sts0_bytessent_high abstract data model elements (section 3.3.1.1). The server MUST respond by sending the bytes read to the client via the SMB transport.