Export (0) Print
Expand All

6 Appendix A: Windows Behavior

The information in this specification is applicable to the following versions of Windows:

  • Windows Vista
  • Windows Server 2008

Exceptions, if any, are noted below. Unless otherwise specified, any statement of optional behavior in this specification prescribed using the terms SHOULD or SHOULD NOT implies Windows behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that Windows does not follow the prescription.

<1> Section 1.6: The Server Message Block (SMB) Version 2.0 Protocol is only available in Windows Vista–based clients and servers. Windows Vista–based clients and servers default to using the SMB 2.0 Protocol when it is available. All other releases only support the SMB Protocol, as specified in [MS-SMB], and thus use it by default.

<2> Section 2.2.2: Windows–based SMB2 servers leave this one byte of ErrorData uninitialized and it might contain any value.

<3> Section 2.2.2.1: Windows servers will never follow a symlink. It is the client's responsibility to evaluate the symlink and access the actual file using the symlink. A Windows server only returns STATUS_STOPPED_ON_SYMLINK when the open fails due to presence of a symlink.

<4> Section 2.2.2.1: Windows Vista and Windows Server 2008s will return an absolute target to a local resource in the format of "\??\C:\..." where C: is the drive mount point on the local system and ... is replaced by the remainder of the path to the target.

<5> Section 2.2.3: A Windows Vista RTM–based client would send a value of zero in Dialects array in SMB2_NEGOTIATE_Request and a Windows Vista RTM based server would acknowledge with a value of 6 in DialectRevision in SMB2 NEGOTIATE Response. This behavior is deprecated.

<6> Section 2.2.4: A Windows Vista RTM–based client would send a value of zero in Dialects array in SMB2_NEGOTIATE_Request and a Windows Vista RTM–based server would acknowledge with a value of 6 in DialectRevision in SMB2 NEGOTIATE Response. This behavior is deprecated.

<7> Section 2.2.4: Windows–based SMB2 servers generate a new ServerGuid each time they are started.

<8> Section 2.2.4: Windows clients do not enforce the MaxTransactSize value.

<9> Section 2.2.5: Windows clients set this bit to any value.

<10> Section 2.2.5: Windows clients set this bit to any value.

<11> Section 2.2.5: Windows clients set this bit to any value.

<12> Section 2.2.9: The Windows SMB 2.0 Protocol client translates any names of the form \\server\pipe to \\server\IPC$ before sending a request on the network.

<13> Section 2.2.13: Windows-based clients never use exclusive oplocks. Because there are no situations where the client would want an exclusive oplock where it would not also want an SMB2_OPLOCK_LEVEL_BATCH, it always requests an SMB2_OPLOCK_LEVEL_BATCH.

<14> Section 2.2.13: When opening an existing file, Windows clients set this field to any value, and Windows-based servers ignore this value.

<15> Section 2.2.13: When opening a printer file or a named pipe, Windows-based servers ignore these ShareAccess values.

<16> Section 2.2.13: When opening a printer object, Windows-based servers ignore this value.

<17> Section 2.2.13: When opening a printer object, Windows-based servers ignore this value.

<18> Section 2.2.13: When opening a printer object, Windows-based servers ignore this value.

<19> Section 2.2.13: If any of the reserved bits are set, Windows server implementations return STATUS_NOT_SUPPORTED.

<20> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<21> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<22> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<23> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<24> Section 2.2.13: Windows SMB2 clients do not initialize this bit. The bit contains the value specified by the caller when requesting the open.

<25> Section 2.2.13: Windows NT 4.0 fails the CREATE request with STATUS_INVALID_PARAMETER if this bit is set.

<26> Section 2.2.13: Windows-based clients always set the NameOffset to the offset of the Buffer field from the beginning of the SMB2 header.

<27> Section 2.2.13: Windows-based clients always set the NameOffset to the offset of the Buffer field from the beginning of the SMB2 header.

<28> Section 2.2.13.1.1: Windows sets this flag to the value passed in by the higher-level application.

<29> Section 2.2.13.1.1: Windows fails the create request with STATUS_ACCESS_DENIED if the caller does not have the AccessSystemAcl privilege.

<30> Section 2.2.13.1.2: Windows sets this flag to the value passed in by the higher-level application.

<31> Section 2.2.13.2.3: Windows-based SMB2 Server implementations allow a durable open only on an SMB2_CREATE with a RequestedOplockLevel of SMB2_OPLOCK_LEVEL_BATCH.

<32> Section 2.2.14: Windows-based clients never use exclusive oplocks. Because there are no situations where it would want an exclusive oplock where it would not also want an SMB2_OPLOCK_LEVEL_BATCH, it always requests an SMB2_OPLOCK_LEVEL_BATCH.

<33> Section 2.2.14: Windows-based SMB2 servers MAY set this field to any value.

<34> Section 2.2.14.2.4: Windows servers send an SMB2 CREATE_CONTEXT response as specified in section 2.2.13.2.3.

<35> Section 2.2.23: Windows-based clients never use exclusive oplocks. Because there are no situations where it would want an exclusive oplock where it would not also want an SMB2_OPLOCK_LEVEL_BATCH, it always requests an SMB2_OPLOCK_LEVEL_BATCH.

<36> Section 2.2.24: Windows-based clients never use exclusive oplocks. There are no situations where an exclusive oplock would be used instead of using a SMB2_OPLOCK_LEVEL_BATCH.

<37> Section 2.2.25: Windows-based clients never use exclusive oplocks. There are no situations where an exclusive oplock would be used instead of using a SMB2_OPLOCK_LEVEL_BATCH.

<38> Section 2.2.31: If no input data is required for the FSCTL/IOCTL command being issued, Windows-based clients set this field to any value.

<39> Section 2.2.31: Windows clients set the OutputOffset field equal to the InputOffset field.

<40> Section 2.2.31.1.1: Windows sets this field to any value.

<41> Section 2.2.32: For the following FSCTLs, InputOffset is set to the same value as that received in the IOCTL request.

  • FSCTL_ALLOW_EXTENDED_DASD_IO
  • FSCTL_FIND_FILES_BY_SID
  • FSCTL_GET_RETRIEVAL_POINTERS
  • FSCTL_QUERY_ALLOCATED_RANGES
  • FSCTL_READ_FILE_USN_DATA
  • FSCTL_RECALL_FILE
  • FSCTL_WRITE_USN_CLOSE_RECORD

Otherwise, Windows–based SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<42> Section 2.2.32: Windows–based SMB2 servers set InputCount to the same value as the value received in the IOCTL request for the following FSCTLs.

  • FSCTL_ALLOW_EXTENDED_DASD_IO
  • FSCTL_FIND_FILES_BY_SID
  • FSCTL_GET_RETRIEVAL_POINTERS
  • FSCTL_QUERY_ALLOCATED_RANGES
  • FSCTL_READ_FILE_USN_DATA
  • FSCTL_RECALL_FILE
  • FSCTL_WRITE_USN_CLOSE_RECORD

Windows clients ignore the InputCount field.

<43> Section 2.2.32: Windows–based SMB2 servers set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<44> Section 2.2.32.3: Windows Server 2003, Windows Vista, and Windows Server 2008s do not zero out the extra bytes of the Context field.

<45> Section 2.2.33: Windows-based servers do not support this value.

<46> Section 2.2.37: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<47> Section 2.2.37: Windows client and server will send a 1-byte buffer of 0, even if InputbufferLength is set to 0.

<48> Section 2.2.37.1: Windows-based clients will always request quota information by using a SidList, which is a linked list of one or more FILE_GET_QUOTA_INFORMATION structures.

<49> Section 3.1.3: By default, Windows-based clients and servers set the RequireMessageSigning value to TRUE for domain controllers and FALSE for all other machines.

<50> Section 3.2.1.3: Windows clients do not enforce the MaxTransactSize value.

<51> Section 3.2.2.1: The Windows-based client implements this timer with a default value of 60 seconds.

<52> Section 3.2.2.2: The Windows-based client uses this timer with a default time-out value of 10 seconds.

<53> Section 3.2.4.1.1: A client can selectively sign requests, and the server will sign the corresponding responses. Windows-based clients do not selectively sign requests.

<54> Section 3.2.4.1.2: The Windows-based client will request credits up to a configured maximum. That maximum is 128 by default. A Windows-based client sends a value of 0 for an SMB2 NEGOTIATE Request and expects the server to grant at least 1 credit.

<55> Section 3.2.4.1.4: Windows SMB2 Server allows a mix of related and unrelated compound requests in the same transport send. Upon encountering a request with SMB2_FLAGS_RELATED_OPERATIONS not set Windows SMB2 Server treats it as the start of a chain.

<56> Section 3.2.4.1.4: Windows Vista and Windows Server 2008s will align their compounded requests and responses on 8-byte boundaries. Currently they do not disconnect other machines that disobey this rule.

<57> Section 3.2.4.1.4: The Windows-based client does not send unrelated compounded requests.

<58> Section 3.2.4.1.4: Windows-based clients will compound certain related requests to improve performance, usually combining a Create with another operation, such as an attribute query.

<59> Section 3.2.4.2: Windows-based clients always set up a new transport connection when establishing a new session to a server.

<60> Section 3.2.4.2.1: Windows-based SMB2 clients always establish a new TCP connection to the server for each session.

<61> Section 3.2.4.2.2: The Windows-based client will initiate a multi-protocol negotiation unless it has previously negotiated with this server and determined that it supports the SMB 2.0 Protocol. In the latter case, it will initiate an SMB2-only negotiate.

<62> Section 3.2.4.2.2.1: When a Windows based client sends the deprecated "SMB2.001" dialect, a Windows Vista RTM–based server would acknowledge with a value of 6 in DialectRevision in SMB2 NEGOTIATE Response. This behavior is deprecated.

<63> Section 3.2.4.2.2.2: Windows-based clients set Capabilities, ClientGuid, and ClientStartTime to 0.

<64> Section 3.2.4.2.3: Windows-based clients implement the first option that is specified.

<65> Section 3.2.4.2.3: All the GSS-API tokens used by Windows SMB2 clients are up to 4Kbytes in size. SMB2 servers always instruct the GSS_API server to expect the GSS_C_FRAGMENT_TO_FIT.

<66> Section 3.2.4.2.3: Windows SMB2 client does not set the SMB2_NEGOTIATE_SIGNING_ENABLED bit if RequireMessageSigning is TRUE.

<67> Section 3.2.4.2.3.1: Windows-based clients implement the first option that is specified.

<68> Section 3.2.4.2.3.1: All the GSS-API tokens used by Windows SMB2 clients are up to 4Kbytes in size. SMB2 servers always instruct the GSS_API server to expect the GSS_C_FRAGMENT_TO_FIT.

<69> Section 3.2.4.2.3.1: Windows SMB2 Client does not set the SMB2_NEGOTIATE_SIGNING_ENABLED bit if RequireMessageSigning is TRUE.

<70> Section 3.2.4.3: Windows-based clients will request a batch oplock for file creates.

<71> Section 3.2.4.4: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<72> Section 3.2.4.5: Windows-based clients will attempt to reconnect to opens if durability was granted at open time.

<73> Section 3.2.4.5: Windows-based clients will try to send multiple read commands at the same time, starting at the lowest offset and working to the highest.

<74> Section 3.2.4.6: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<75> Section 3.2.4.6: Windows-based clients always put the payload at the beginning of the Buffer field and do not insert padding.

<76> Section 3.2.4.6: Windows-based clients will try to send multiple write commands at the same time, starting at the lowest offset and working to the highest.

<77> Section 3.2.4.7: Windows clients will attempt to reconnect to an open if durability was granted at open time.

<78> Section 3.2.4.7: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<79> Section 3.2.4.8: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<80> Section 3.2.4.9: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<81> Section 3.2.4.9: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<82> Section 3.2.4.10: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<83> Section 3.2.4.11: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<84> Section 3.2.4.11: Windows clients set this value to the offset from the start of the SMB2 header to the beginning of the Buffer field.

<85> Section 3.2.4.12: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<86> Section 3.2.4.13: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<87> Section 3.2.4.14: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<88> Section 3.2.4.15: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<89> Section 3.2.4.16: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<90> Section 3.2.4.17: Windows-based clients will attempt to reconnect to an open if durability was granted at the open time.

<91> Section 3.2.4.18: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<92> Section 3.2.4.19.1: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<93> Section 3.2.4.19.1: Windows clients set this field to any value.

<94> Section 3.2.4.19.1: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<95> Section 3.2.4.19.2: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<96> Section 3.2.4.19.2: Windows clients set this field to any value.

<97> Section 3.2.4.19.2: Windows clients set this field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<98> Section 3.2.4.19.2: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<99> Section 3.2.4.19.2: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<100> Section 3.2.4.19.3: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<101> Section 3.2.4.19.4: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<102> Section 3.2.4.19.4: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<103> Section 3.2.4.19.5: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<104> Section 3.2.4.19.5: Windows clients set this field to any value.

<105> Section 3.2.4.19.5: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<106> Section 3.2.4.19.6: Windows-based SMB2 servers do not support IOCTL requests.

<107> Section 3.2.4.19.6: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<108> Section 3.2.4.19.6: Windows clients set the OutputOffset field to InputOffset + InputCount, rounded up to a multiple of 8 bytes.

<109> Section 3.2.4.20: Windows-based clients will attempt to reconnect to an open if durability was granted at open time.

<110> Section 3.2.5.1.2: Windows-based clients will not disconnect the connection but simply disregard the incorrectly signed response.

<111> Section 3.2.5.1.6: Windows-based clients will not disconnect the connection, but will simply fail the request.

<112> Section 3.2.5.1.7: Windows-based SMB 2.0 Protocol clients do not check the validity of the command in the response.

<113> Section 3.2.5.2: Windows-based clients will not use the MaxTransactSize and will use the ServerGuid to determine if the client and server are the same machine.

<114> Section 3.2.5.14: Windows servers will reject any response where OutputOffset + OutputCount exceeds the size of the SMB2 response.

<115> Section 3.2.5.19.1: Windows-based clients will not request exclusive oplocks.

<116> Section 3.2.6.1: The Windows-based client will fail requests for which no reply is received within the default time-out.

<117> Section 3.2.6.1: The Windows-based client will not disconnect the connection.

<118> Section 3.2.6.2: The Windows-based client will disconnect idle connections that have no open files and that have had no activity for 10 seconds.

<119> Section 3.3.1.2: Windows-based servers will limit the maximum range of sequence numbers. If a client has been granted 10 credits, the server will not allow the difference between the smallest available sequence number and the largest available sequence number to exceed 2*10 = 20. Therefore, if the client has sequence number 10 available and does not send it, the server will stop granting credits as the client nears sequence number 30, and eventually will grant no further credits until the client sends sequence number 10.

<120> Section 3.3.1.3: Windows Vista SP1 and Windows Server 2008–based SMB2 clients require a minimum of 4 credits to be granted by the server.

<121> Section 3.3.1.3: A Windows-based server will grant some portion of the client request based on available resources and the number of credits the client is currently taking advantage of. A Windows–based server grants credits based on usage but will attempt to enforce fairness if there are insufficient credits.

<122> Section 3.3.1.3: A Windows–based server does not currently scale credits based on quality of service features.

<123> Section 3.3.1.6: Windows-based servers allow the sharing of both printers and traditional file shares.

<124> Section 3.3.1.6: In Windows, this abstract state element contains the security descriptor for the share.

<125> Section 3.3.2.1: This timer has a default value of 35 seconds, but its value could be changed by system policy to any range between 5 seconds and infinite (4,294,967,295 seconds).

<126> Section 3.3.2.2: This timer has a default value of 16 minutes, but its value could be changed by system policy to any range between 5 seconds and infinite (4,294,967,295 seconds).

<127> Section 3.3.3: By default, Windows-based servers listen on both TCP-445 and NetBIOS. They can be configured to use only TCP-445 by disabling NetBIOS over TCP. Likewise, they can also pick up this setting via policy or DHCP configuration.

<128> Section 3.3.3: Windows-based SMB2 servers generate a new ServerGuid each time they are started.

<129> Section 3.3.4.1.1: Windows-based servers do not sign interim responses.

<130> Section 3.3.4.1.2: Windows Vista and Windows Server 2008 do not grant credits on interim responses. An interim response for an asynchronously processed SMB2 CHANGE_NOTIFY request will grant credits to keep the transaction from stalling in case the client is out of credits.

<131> Section 3.3.4.1.3: The Windows-based server compounds responses for any received compounded operations. Otherwise, it does not compound responses.

<132> Section 3.3.4.1.3: Windows-based servers grant all credits in the final response of the compounded chain, and grant 0 credits in all responses other than the final response.

<133> Section 3.3.4.2: Windows-based servers send interim responses for the following operations if they cannot be completed immediately:

  • SMB2_CREATE, when the server is in oplock break for the file under consideration
  • SMB2_CHANGE_NOTIFY
  • Byte Range Lock
  • Named Pipe Read on a blocking named pipe
  • Named Pipe Write on a blocking named pipe
  • FSCTL_PIPE_TRANSCEIVE

Windows servers allot a certain number of blocking operations with a statically configured blocking operation credit, which defaults to 50 but is configurable. If a client attempts to exceed this maximum number of blocking operations, the server will fail the request.

<134> Section 3.3.4.2: Windows servers always fail requests that go to async mode in a compound request with STATUS_INTERNAL_ERROR except for the following two cases: when a create request in the compound request triggers an oplock break, or when the last request in the compound request wants to go async mode.

<135> Section 3.3.5.2.2: Windows-based servers will not fail the request with an error code but will disconnect clients who send requests with an invalid MessageId.

<136> Section 3.3.5.2.3: Windows-based servers will not disconnect the connection due to a mismatched signature.

<137> Section 3.3.5.2.3: Windows-based servers will not disconnect the connection due to an unsigned packet.

<138> Section 3.3.5.2.4: Windows-based servers will disconnect the connection when it processes packets that are smaller than the SMB2 header or packets that contain an invalid SMB2 command. For all other validations, it will not disconnect the connection but simply return the error.

<139> Section 3.3.5.2.5: Windows–based SMB2 servers always fail requests that go to async mode in a compound request with STATUS_INTERNAL_ERROR except for the following two cases: when a create request in the compound request triggers an oplock break, or when the last request in the compound request goes to async mode. If multiple requests in a compound message go to async mode, only the first request will be responded to by Windows–based SMB2 servers. Subsequent async requests will be ignored by Windows–based SMB2 server implementations. Responses for the requests prior to the first async request are sent as part of a single response. Other responses are returned in separate messages.

<140> Section 3.3.5.2.5.2: If the SMB2_FLAGS_RELATED_OPERATIONS is present in the first request the following responses are sent if the request requires a SessionId, TreeId or FileId. If the request requires a SessionId, Windows servers will fail the operation with a STATUS_USER_SESSION_DELETED. If the request requires a TreeId, Windows servers will fail the operation with a STATUS_NETWORK_NAME_DELETED. If the request requires a FileId, Windows servers will fail the operation with a STATUS_FILE_CLOSED. All other operations will succeed.

<141> Section 3.3.5.3: When a Windows–based client sends the deprecated "SMB2.001" dialect, a Windows Vista RTM–based server would acknowledge with a value of 6 in DialectRevision in SMB2_NEGOTIATE_Response. This behavior is deprecated.

<142> Section 3.3.5.3: A Windows Vista RTM–based server sets DialectRevision to 6.

<143> Section 3.3.5.3: Windows clients do not enforce the MaxTransactSize value.

<144> Section 3.3.5.4: Windows-based SMB2 server implementations allow multiple negotiate requests on the same connection.

<145> Section 3.3.5.4: A Windows Vista RTM–based server checks to see if the dialect number zero was provided in the Dialect array of the SMB2_REQ_NEGOTIATE request. If it is not found, the server fails the request with STATUS_NOT_SUPPORTED.

<146> Section 3.3.5.5: Windows Vista and Windows Server 2008s will fail the request with STATUS_REQUEST_NOT_ACCEPTED.

<147> Section 3.3.5.9: If the target of the create request is a file, and any of the bits in the mask 0x0CE0FE00 are set, Windows allows the file open but does not allow any operations on the opened file.

<148> Section 3.3.5.9: Windows-based servers ignore DesiredAccess values other than FILE_WRITE_DATA, FILE_APPEND_DATA and GENERIC_WRITE if any one of these values is specified.

<149> Section 3.3.5.9: Windows-based servers fail requests having a CreateDisposition of FILE_OPEN or FILE_OVERWRITE, but ignore values of FILE_SUPERSEDE, FILE_OPEN_IF and FILE_OVERWRITE_IF.

<150> Section 3.3.5.9: Windows Vista and Windows Server 2008 ignore create contexts having a NameLength greater than 4.

<151> Section 3.3.5.9.2: Windows will ignore security descriptors if the underlying file system does not support them.

<152> Section 3.3.5.9.3: Windows-based servers support this request.

<153> Section 3.3.5.11: Windows-based servers handle this request asynchronously.

<154> Section 3.3.5.12: Windows SMB2 servers send an interim response to the client and handle the read asynchronously if the read is not finished in 0.5 milliseconds.

<155> Section 3.3.5.12: Windows-based servers handle the following commands asynchronously: SMB2 Create (section 2.2.13) when this create would result in an oplock break, SMB2 IOCTL Request (section 2.2.31) for FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond, SMB2 Change_Notify Request (section 2.2.35) if it blocks for more than 0.5 milliseconds, SMB2 Read request (section 2.2.19) for named pipes if it blocks for more than 0.5 milliseconds, SMB2 Write request (section 2.2.21) for named pipes if it blocks for more than 0.5 milliseconds, and SMB2 lock request (section 2.2.26) if the SMB2_LOCKFLAG_FAIL_IMMEDIATELY flag is not set.

<156> Section 3.3.5.12: Windows servers ignore the Padding field and set the DataOffset field to 0x50.

<157> Section 3.3.5.13: Windows-based servers handle the following commands asynchronously:

<158> Section 3.3.5.14.1: Windows-based servers ignore this value while processing Unlocks.

<159> Section 3.3.5.14.2: Windows-based servers check for SMB2_LOCKFLAG_FAIL_IMMEDIATELY only for the first element of the Locks array.

<160> Section 3.3.5.15.1: Windows SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<161> Section 3.3.5.15.2: A Windows-based DFS server does not return any data to the caller if the buffer supplied to FSCTL_GET_DFS_REFERRALS is too small.

<162> Section 3.3.5.15.2: Windows–based servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<163> Section 3.3.5.15.3: Windows Vista, Windows Vista SP1, Windows Server 2008 and Windows Server 2008 SP1 will send back the input buffer based on the InputOffset and InputCount indicated in the request.

<164> Section 3.3.5.15.3: Windows SMB2 servers send an interim response to the client if the read/write attempt is not finished in 1 ms.

<165> Section 3.3.5.15.3: Windows–based SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<166> Section 3.3.5.15.3: Windows–based SMB2 servers currently return the input buffer that was received in the request as part of the response.

<167> Section 3.3.5.15.3: Windows–based SMB2 servers currently return the input buffer that was received in the request as part of the response.

<168> Section 3.3.5.15.3: Windows–based SMB2 servers set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<169> Section 3.3.5.15.4: Windows SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<170> Section 3.3.5.15.4: Windows SMB2 servers will set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<171> Section 3.3.5.15.5: Windows servers do not support any additional contexts.

<172> Section 3.3.5.15.5: Windows servers construct the 24-byte blob using the Open.Durable field and other pieces of information which include the process ID of the caller and a timestamp.

<173> Section 3.3.5.15.5: Windows SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<174> Section 3.3.5.15.6: Windows servers will return STATUS_INVALID_VIEW_SIZE instead of STATUS_END_OF_FILE.

<175> Section 3.3.5.15.6: Windows SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<176> Section 3.3.5.15.6.1: Windows-based SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<177> Section 3.3.5.15.6.2: Windows SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<178> Section 3.3.5.15.6.2: Windows Server 2003, Windows Vista, and Windows Server 2008 will accept a maximum of 256 chunks in a single operation, each chunk must be less than or equal to 1 megabyte, and the total data size must be less than or equal to 16 megabytes.

<179> Section 3.3.5.15.7: Windows-based SMB2 servers do not support IOCTL requests and fail the request with STATUS_INVALID_DEVICE_REQUEST.

<180> Section 3.3.5.15.7: Windows-based SMB2 servers set the InputOffset field to the offset, in bytes, from the beginning of the SMB2 header to the Buffer[] field of the response.

<181> Section 3.3.5.15.7: Windows-based SMB2 servers will set OutputOffset to InputOffset + InputCount, rounded up to a multiple of 8.

<182> Section 3.3.5.18: NTFS does not support resuming queries by index number that are provided by the client.

<183> Section 3.3.5.19: Windows-based servers handle the following commands asynchronously: SMB2 Create (section 2.2.13) when this create would result in an oplock break, SMB2 IOCTL Request (section 2.2.31) for FSCTL_PIPE_TRANSCEIVE if it blocks for more than 1 millisecond, SMB2 Change_Notify Request (section 2.2.35) if it blocks for more than 0.5 milliseconds, SMB2 Read request (section 2.2.19) for named pipes if it blocks for more than 0.5 milliseconds, SMB2 Write request (section 2.2.21) for named pipes if it blocks for more than 0.5 millseconds, and SMB2 lock request (section 2.2.26) if the SMB2_LOCKFLAG_FAIL_IMMEDIATELY flag is not set.

<184> Section 3.3.5.20.1: Windows-based SMB2 servers fail the following request levels with STATUS_NOT_SUPPORTED instead of STATUS_INVALID_INFO_CLASS: 9, 26, 29, 41-50.

<185> Section 3.3.5.20.4: Windows-based servers do support quotas, if configured.

<186> Section 3.3.5.21.1: Windows-based SMB2 servers fail the following request levels with STATUS_NOT_SUPPORTED instead of STATUS_INVALID_INFO_CLASS: 15, 25, 27, 29, 30, 31, 32, 36, 41-44.

<187> Section 3.3.5.21.3: If the underlying object store does not support object security based on Access Control Lists (as specified in [MS-DTYP] section 2.4.5), it returns STATUS_SUCCESS.

<188> Section 3.3.5.21.4: Windows servers do support quotas, if configured.

Show:
© 2014 Microsoft