| Name | Description |
|---|---|
| Access_Mask_Encoding | The SMB2 Access Mask Encoding in SMB2 is a 4-byte bit field value that contains an array of flags. Each access mask MUST be a combination of zero or more of the bit positions that are shown below. |
| ApplicationSpecificSmb2Status | |
| CANCEL_Request | The SMB2 CANCEL Request packet is sent by the client to cancel a previously sent message on the same SMB2 transport connection. The MessageId of the request to be canceled MUST be set in the SMB2 header of the request. This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| CHANGE_NOTIFY_Request | The SMB2 CHANGE_NOTIFY Request packet is sent by the client to register for change notifications on a directory. This request consists of an SMB2 header, as specified in section , followed by this request structure: |
| CHANGE_NOTIFY_Response | The SMB2 CHANGE_NOTIFY Response packet is sent by the server to transmit the results of a client's SMB2 CHANGE_NOTIFY Request. The server MUST send this packet only if a change occurs and MUST NOT send this packet otherwise. This response consists of an SMB2 header, as specified in section , followed by this response structure: |
| CLOSE_Request | The SMB2 CLOSE Request packet is used by the client to close an instance of a file that was opened previously with a successful SMB2 CREATE Request. This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| CLOSE_Response | The SMB2 CLOSE Response packet is sent by the server to indicate that an SMB2 CLOSE Request was processed successfully. This response is composed of an SMB2 header, as specified in section , followed by this response structure: |
| CREATE_ALLOCATION_SIZE | The SMB2 CREATE_ALLOCATION_SIZE context is specified on an SMB2 CREATE Request when the client is setting the initial allocation size of a newly created file. The Data field of the SMB2_CREATE_CONTEXT MUST be as follows: |
| CREATE_APP_INSTANCE_ID | The SMB2_CREATE_APP_INSTANCE_ID context is specified on an SMB2 CREATE Request when the client is supplying an identifier provided by an application. The SMB2_CREATE_APP_INSTANCE_ID context is only valid for the SMB 3.x dialect family. |
| CREATE_APP_INSTANCE_VERSION | The SMB2_CREATE_APP_INSTANCE_VERSION context is specified on an SMB2 CREATE Request when the client is supplying a version for the app instance identifier provided by an application. The SMB2_CREATE_APP_INSTANCE_VERSION context is only valid for the SMB 3.1.1 dialect. |
| CREATE_CONTEXT | The SMB2_CREATE_CONTEXT structure is used by the SMB2 CREATE Request and the SMB2 CREATE Response to encode additional flags and attributes: in requests to specify how the CREATE request MUST be processed, and in responses to specify how the CREATE request was in fact processed.There is no required ordering when multiple create context structures are used. The server MUST support receiving the contexts in any order.Each structure takes the following form: |
| CREATE_DURABLE_HANDLE_RECONNECT | The SMB2 CREATE_DURABLE_HANDLE_RECONNECT context is specified when the client is attempting to reestablish a durable open as specified in section. |
| CREATE_DURABLE_HANDLE_RECONNECT_V2 | The SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2 context is specified when the client is attempting to reestablish a durable open as specified in section 3.2.4.4. The SMB2_CREATE_DURABLE_HANDLE_RECONNECT_V2 context is valid only for the SMB 3.x dialect family. |
| CREATE_DURABLE_HANDLE_REQUEST | The SMB2_CREATE_DURABLE_HANDLE_REQUEST context is specified on an SMB2 CREATE Request when the client is requesting that the open be durable (that is, that it allow reestablishment after disconnect). It MUST NOT be used for pipes. The format of the Data field of this SMB2_CREATE_CONTEXT MUST be as follows: |
| CREATE_DURABLE_HANDLE_REQUEST_V2 | The SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 context is only valid for the SMB 3.x dialect family. The SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 context is specified in an SMB2 CREATE request when the client requests the server to mark the open as durable or persistent. |
| CREATE_DURABLE_HANDLE_RESPONSE | If the server succeeds in opening a durable handle to a file as requested by the client via the SMB2_CREATE_DURABLE_HANDLE_REQUEST , it MUST send an SMB2 CREATE_DURABLE_HANDLE_RESPONSE back to the client to inform the client that the handle is durable.If the server does not mark it for durable operation or the server does not implement durable handles, then it MUST ignore this request. |
| CREATE_DURABLE_HANDLE_RESPONSE_V2 | |
| CREATE_EA_BUFFER | The SMB2_CREATE_EA_BUFFER context is specified on an SMB2 CREATE Request (section 2.2.13) when the client is applying extended attributes as part of creating a new file. |
| CREATE_QUERY_MAXIMAL_ACCESS_REQUEST | The SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST context is specified on an SMB2 CREATE Request when the client is requesting the server to retrieve maximal access information as part of processing the open. |
| CREATE_QUERY_MAXIMAL_ACCESS_RESPONSE | The SMB2 CREATE_QUERY_MAXIMAL_ACCESS returns an SMB2_CREATE_CONTEXT in the response with the Name that is identified by SMB2_CREATE_QUERY_MAXIMAL ACCESS as specified in SMB2_CREATE_CONTEXT Request Values, if the server attempts to query maximal access as part of processing a create request. |
| CREATE_QUERY_ON_DISK_ID_RESPONSE | |
| CREATE_REQUEST_LEASE | The SMB2_CREATE_REQUEST_LEASE context is specified on an SMB2 CREATE Request (section 2.2.13) packet when the client is requesting the server to return a lease. This is only valid for the SMB 2.1 dialect. |
| CREATE_REQUEST_LEASE_V2 | The SMB2_CREATE_REQUEST_LEASE_V2 context is specified on an SMB2 CREATE Request when the client is requesting the server to return a lease on a file or a directory. This is valid only for the SMB 3.x dialect family. |
| CREATE_RESPONSE_LEASE | The server responds with a lease that is granted for this open. |
| CREATE_RESPONSE_LEASE_V2 | |
| CREATE_Request | When the server receives an SMB2 CREATE Request, it MUST create a file if the file does not exist; otherwise, it MUST open the existing file. In case of a named pipe or printer, the server MUST create a new file.This request is composed of an SMB2 header, as specified in section , that is followed by this request structure: |
| CREATE_Response | The SMB2 CREATE Response packet is sent by the server to notify the client of the status of its SMB2 CREATE Request. This response is composed of an SMB2 header, as specified in section , followed by this response structure: |
| CREATE_SD_BUFFER | The SMB2_CREATE_SD_BUFFER context is specified on an SMB2 CREATE Request when the client is applying a security descriptor to a newly created file. |
| CREATE_TIMEWARP_TOKEN | The SMB2_CREATE_TIMEWARP_TOKEN context is specified on an SMB2 CREATE Request when the client is requesting the server to open a version of the file at a previous point in time. The Data field of the SMB2_CREATE_CONTEXT MUST contain the following structure: |
| CreateContextNames | The const strings of Create Context Name. |
| ECHO_Request | The SMB2 ECHO Request packet is sent by a client to determine whether a server is processing requests. This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| ECHO_Response | The SMB2 ECHO Response packet. |
| ERROR_Response_packet | The SMB2 ERROR Response packet is sent by the server to respond to a request that has failed or encountered an error. This response is composed of an SMB2 Packet Header followed by this response structure: |
| EXTENTS | The EXTENTS data element is as follows. |
| ErrefStatus | |
| ErrorData_Format | |
| Error_Context | Error Context in error response |
| FILEID | The SMB2 FILEID is used to represent an open to a file. |
| FILE_ACCESS_INFORMATION | This information class is used to query or set the access rights of the file. The FILE_ACCESS_INFORMATION data element is as follows. |
| FILE_ALL_INFORMATION | This information class is used to query a collection of file information structures. |
| FILE_FS_DEVICE_INFORMATION | This information class is used to query device information associated with a file system volume. The message contains a FILE_FS_DEVICE_INFORMATION data element. The FILE_FS_DEVICE_INFORMATION data element is as follows. |
| FILE_LINK_ENTRY_INFORMATION | The FILE_LINK_ENTRY_INFORMATION packet is used to describe a single NTFS hard link to an existing file. |
| FILE_MODE_INFORMATION | This information class is used to query or set the mode of the file. The FILE_MODE_INFORMATION data element is as follows. |
| FILE_NOTIFY_INFORMATION | The FILE_NOTIFY_INFORMATION packet is sent in the SMB2 CHANGE_NOTIFY Response to return the changes that the client is being notified of. The structure consists of the following: |
| FILE_OBJECTID_BUFFER_Type_1 | The first possible structure for the FILE_OBJECTID_BUFFER data element follows. |
| FILE_OBJECTID_BUFFER_Type_2 | The second possible structure for the FILE_OBJECTID_BUFFER data element follows. |
| FILE_PIPE_REMOTE_INFORMATION | This information class is used to query or set information on a named pipe that is associated with the client end of the pipe that is being queried.Remote information is not available for local pipes or for the server end of a remote pipe. The FILE_PIPE_REMOTE_INFORMATION data element is as follows. |
| FILE_POSITION_INFORMATION | This information class is used to query the position of the file pointer within a file. The FILE_POSITION_INFORMATION data element is as follows. |
| FLUSH_Request | The SMB2 FLUSH Request packet is sent by a client to request that a server flushes all cached file information for a specified open of a file to the persistent store that backs the file. It is also sent for a specified open of a named pipe to be completed when all data that is written to the named pipe has been read by the server side of the pipe. This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| FLUSH_Response | The SMB2 FLUSH Response packet is sent by the server to confirm that an SMB2 FLUSH Request was successfully processed. This response is composed of an SMB2 header, as specified in section , followed by this request structure: |
| FSCTL_FIND_FILES_BY_SID_Reply | The FSCTL_FIND_FILES_BY_SID reply message returns the results of the FSCTL_FIND_FILES_BY_SID request as an array of FIND_BY_SID_OUTPUT data elements, one for each matching file that is found.The FIND_BY_SID_OUTPUT data element is as follows. |
| FSCTL_GET_COMPRESSION_Reply | The FSCTL_GET_COMPRESSION reply message returns the results of the FSCTL_GET_COMPRESSION request as a 16-bit unsigned integer value that indicates the current compression state of the file or directory.The CompressionState element is as follows. |
| FSCTL_GET_RETRIEVAL_POINTERS_Reply | The FSCTL_GET_RETRIEVAL_POINTERS reply message returns the results of the FSCTL_GET_RETRIEVAL_POINTERS request as a variably sized data element, RETRIEVAL_POINTERS_BUFFER, that specifies the allocation and location on disk of a specific file.For the NTFS file system, the FSCTL_GET_RETRIEVAL_POINTERS reply returns the extent locations (that is, locations of allocated regions of disk space) of nonresident data. A file system MAY allow resident data, which is data that can be written to disk within the file's directory record. Because resident data requires no additional disk space allocation, no extent locations are associated with resident data.On an NTFS volume, very short data streams (typically several hundred bytes) can be written to disk without having any clusters allocated. These short streams are sometimes called resident because the data resides in the file's master file table (MFT) record. A resident data stream has no retrieval pointers to return.The RETRIEVAL_POINTERS_BUFFER data element is as follows. |
| FSCTL_GET_RETRIEVAL_POINTERS_Request | The FSCTL_GET_RETRIEVAL_POINTERS request message requests that the server return a variably sized data element, StartingVcn, that describes the location on disk of the file or directory associated with the handle on which this FSCTL was invoked. It is most commonly used by defragmentation utilities. This data element describes the mapping between virtual cluster numbers and logical cluster numbers.The STARTING_VCN_INPUT_BUFFER data element is as follows. |
| FSCTL_IS_PATHNAME_VALID_Request | The FSCTL_IS_PATHNAME_VALID request message requests that the server return whether or not the specified path name associated with the handle on which this FSCTL was invoked is composed of valid characters with respect to the remote file system storage.The data element is as follows. |
| FSCTL_LMR_GET_LINK_TRACKING_INFORMATION_Reply | The FSCTL_LMR_GET_LINK_TRACKING_INFORMATION reply message returns the results of the FSCTL_LMR_GET_LINK_TRACKING_INFORMATION request. The LINK_TRACKING_INFORMATION data element is as follows. |
| FSCTL_LMR_SET_LINK_TRACKING_INFORMATION_Request | The FSCTL_LMR_SET_LINK_TRACKING_INFORMATION request message sets distributed link tracking information such as file system type, volume ID, object ID, and destination computer's NetBIOS name for the file associated with the handle on which this FSCTL was invoked. The message contains a REMOTE_LINK_TRACKING_INFORMATION data element. For more information on distributed link tracking, see [MS-DLTW] section 3.1.6.The REMOTE_LINK_TRACKING_INFORMATION data element is as follows. |
| FSCTL_PIPE_WAIT_FOR_BUFFER | The FSCTL_PIPE_WAIT request requests that the server wait until either a time-out interval elapses or an instance of the specified named pipe is available for connection. |
| FSCTL_QUERY_ALLOCATED_RANGES_Reply | The FSCTL_QUERY_ALLOCATED_RANGES reply message returns the results of the FSCTL_QUERY_ALLOCATED_RANGES request.This message MUST return an array of zero or more FILE_ALLOCATED_RANGE_BUFFER data elements. The number of FILE_ALLOCATED_RANGE_BUFFER elements returned is computed by dividing the size of the returned output buffer (from SMB, the lower-level protocol that carries the FSCTL) by the size of the FILE_ALLOCATED_RANGE_BUFFER element. Ranges returned are always at least partially within the range specified in the FSCTL_QUERY_ALLOCATED_RANGES request. Zero FILE_ALLOCATED_RANGE_BUFFER data elements MUST be returned when the file has no allocated ranges.Each entry in the output array contains an offset and a length that indicates a range in the file that may contain nonzero data. The actual nonzero data, if any, is somewhere within this range, and the calling application must scan further within the range to locate it and determine if it really is valid data. Multiple instances of valid data may exist within the range.The FILE_ALLOCATED_RANGE_BUFFER data element is as follows. |
| FSCTL_QUERY_ALLOCATED_RANGES_Request | The FSCTL_QUERY_ALLOCATED_RANGES request message requests that the server scan a file or alternate stream looking for byte ranges that may contain nonzero data, and then return information on those ranges. Only sparse files can have zeroed ranges known to the operating system. For other files, the server will return only a single range that contains the starting point and the length requested. The message contains a FILE_ALLOCATED_RANGE_BUFFER data element. The FILE_ALLOCATED_RANGE_BUFFER data element is as follows. |
| FSCTL_READ_FILE_USN_DATA_Reply | The FSCTL_READ_FILE_USN_DATA reply message returns the results of the FSCTL_READ_FILE_USN_DATA request as a USN_RECORD. The USN_RECORD element is as follows. |
| FSCTL_SET_COMPRESSION_Request | The FSCTL_SET_COMPRESSION request message requests that the server set the compression state of the file or directory (associated with the handle on which this FSCTL was invoked) on a volume whose file system supports per-stream compression. The message contains a 16-bit unsigned integer.The CompressionState element is as follows. |
| FSCTL_SET_OBJECT_ID_EXTENDED_Request | The FSCTL_SET_OBJECT_ID_EXTENDED request message requests that the server set the extended information for the file or directory associated with the handle on which this FSCTL was invoked. The message contains an EXTENDED_INFO data element. The EXTENDED_INFO data element is defined as follows. |
| FSCTL_SET_ZERO_DATA_Request | The FSCTL_SET_ZERO_DATA request message requests that the server fill the specified range of the file (associated with the handle on which this FSCTL was invoked) with zeroes. The message contains a FILE_ZERO_DATA_INFORMATION element. The FILE_ZERO_DATA_INFORMATION element is as follows. |
| FSCTL_SIS_COPYFILE_Request | The FSCTL_SIS_COPYFILE request message requests that the server copy the file associated with the handle on which this FSCTL was invoked using the Microsoft Single-Instance Storage (SIS) filter. The message contains an SI_COPYFILE data element. For more information on Single-Instance Storage, see [SIS].If the SIS filter is installed on the server, it will attempt to copy the source file to the destination file by creating an SIS link instead of actually copying the file data. If necessary and allowed, the source file is placed under SIS control before the destination file is created.The SI_COPYFILE data element is as follows. |
| FileAlignmentInformation | The buffer alignment required by the underlying device.The FILE_ATTRIBUTE_INFORMATION data element is as follows. |
| FileAlternateNameInformation | This information class is used to query alternate name information for a file. The alternate name for a file is its 8.3 format name (8 characters that appear before the "." and 3 characters that appear after). This name exists for compatibility with MS-DOS and 16-bit versions of , which did not support longer file names or spaces within file names. A file MAY have an alternate name if its full name is not compliant with the restrictions for file names under MS-DOS and 16-bit .NTFS assigns an alternate name to a file whose full name is not compliant with restrictions for file names under MS-DOS and 16-bit unless the system has been configured through a registry entry to not generate these names to improve performance.The FILE_NAME_INFORMATION data element is as follows. |
| FileAttributeTagInformation | This information class is used to query for attribute and reparse tag information for a file. The FILE_ATTRIBUTE_TAG_INFORMATION data element is as follows. |
| FileBasicInformation | This information class is used to query or set file information.The FILE_BASIC_INFORMATION data element is as follows. |
| FileBothDirectoryInformation | This information class is used to query detailed information for the files in a directory. The FILE_BOTH_DIR_INFORMATION data element is as follows. |
| FileCompressionInformation | This information class is used to query compression information for a file. The FILE_COMPRESSION_INFORMATION data element is as follows. |
| FileDirectoryInformation | This information class is used to query detailed information for the files in a directory.The FILE_DIRECTORY_INFORMATION data element is as follows. |
| FileDispositionInformation | This information class is used to mark a file for deletion. The FILE_DISPOSITION_INFORMATION data element is as follows. |
| FileEaInformation | This information class is used to query for the size of the extended attributes (EA) for a file. An extended attribute is a piece of application-specific metadata that an application can associate with a file that is not part of the file's data. For more information on extended attributes, see [CIFS].The FILE_EA_INFORMATION data element is as follows. |
| FileEndOfFileInformation | This information class is used to set end-of-file information for a file. The FILE_END_OF_FILE_INFORMATION data element is as follows. |
| FileFsAttributeInformation | This information class is used to query attribute information for a file system. The message contains a FILE_FS_ATTRIBUTE_INFORMATION data element. The FILE_FS_ATTRIBUTE_INFORMATION data element is as follows. |
| FileFsControlInformation | This information class is used to query or set quota and content indexing control information for a file system volume. The message contains a FILE_FS_CONTROL_INFORMATION data element. Setting quota information requires the caller to have permission to open a volume handle or handle to the quota index file for write access. The FILE_FS_CONTROL_INFORMATION data element is as follows. |
| FileFsDriverPathInformation | This information class is used to query if a given driver is in the I/O path for a file system volume. The message contains a FILE_FS_DRIVER_PATH_INFORMATION data element. The FILE_FS_DRIVER_PATH_INFORMATION data element is as follows. |
| FileFsFullSizeInformation | This information class is used to query sector size information for a file system volume. The message contains a FILE_FS_FULL_SIZE_INFORMATION data element.The FILE_FS_FULL_SIZE_INFORMATION data element is as follows. |
| FileFsLabelInformation | This information class is used to set the label for a file system volume. The message contains a FILE_FS_LABEL_INFORMATION data element. The FILE_FS_LABEL_INFORMATION data element is as follows. |
| FileFsObjectIdInformation | This information class is used to query or set the object ID for a file system volume. The message contains a FILE_FS_OBJECTID_INFORMATION data element.The FILE_FS_OBJECTID_INFORMATION data element is as follows. |
| FileFsSizeInformation | This information class is used to query sector size information for a file system volume. The message contains a FILE_FS_SIZE_INFORMATION data element. The FILE_FS_SIZE_INFORMATION data element is as follows. |
| FileFsVolumeInformation | This information class is used to query information on a volume on which a file system is mounted. The message contains a FILE_FS_VOLUME_INFORMATION data element. The FILE_FS_VOLUME_INFORMATION data element is as follows. |
| FileFullDirectoryInformation | This information class is used to query detailed information for the files in a directory.The FILE_FULL_DIR_INFORMATION data element is as follows. |
| FileFullEaInformation | This information class is used to query or set extended attribute (EA) information for a file. The FILE_FULL_EA_INFORMATION data element is as follows. |
| FileGetQuotaInformation | The information class is used to provide the list of Security identifiers (SID) for which query quota information is requested. |
| FileIdBothDirectoryInformation | This information class is used to query file reference number information for the files in a directory.The FILE_ID_BOTH_DIR_INFORMATION data element is as follows. |
| FileIdFullDirectoryInformation | This information class is used to query detailed information for the files in a directory. The FILE_ID_FULL_DIR_INFORMATION data element is as follows. |
| FileInternalInformation | This information class is used to query for the file system's 8-byte file reference number for a file.The FILE_INTERNAL_INFORMATION data element is as follows. |
| FileLinkInformation | This information class is used to create an NTFS hard link to an existing file. The FILE_LINK_INFORMATION data element is as follows. |
| FileMailslotQueryInformation | This information class is used to query information on a mailslot.The FILE_MAILSLOT_QUERY_INFORMATION data element is as follows. |
| FileMailslotSetInformation | This information class is used to set information on a mailslot.The FILE_MAILSLOT_SET_INFORMATION data element is as follows. |
| FileNameInformation | This information class is used to query detailed information of a file. The FILE_NAME_INFORMATION data element is as follows. |
| FileNamesInformation | This information class is used to query detailed information on the names of files in a directory.The FILE_NAMES_INFORMATION data element is as follows. |
| FileNetworkOpenInformation | This information class is used to query for information on a network file open. A network file open differs from a file open in that the handle obtained from a network file open can be used to look up attributes using FileNetworkOpenInformation, but it cannot be used for reads and writes to the file. The network file open is an optimization of file open that returns a file handle to the caller more quickly, but the file handle it returns cannot be used in all of the ways that a normal file handle can be used. The FILE_NETWORK_OPEN_INFORMATION data element is as follows. |
| FileObjectIdInformation_Type_1 | The first type of data that may be returned. |
| FileObjectIdInformation_Type_2 | The second type of data that may be returned. |
| FilePipeInformation | This information class is used to query or set information on a named pipe that is not specific to one end of the pipe or another.The FILE_PIPE_INFORMATION data element is as follows. |
| FilePipeLocalInformation | This information class is used to query information on a named pipe that is associated with the end of the pipe that is being queried.The FILE_PIPE_LOCAL_INFORMATION data element is as follows. |
| FileQuotaInformation | The information class is used to query or set quota information.The FILE_QUOTA_INFORMATION data element is as follows. |
| FileRenameInformation | This information class is used to rename a file.The FILE_RENAME_INFORMATION data element is as follows. |
| FileReparsePointInformation | This information class is used to query for information on a reparse point.The FILE_REPARSE_POINT_INFORMATION data element is as follows. |
| FileShortNameInformation | This information class is used to query or change the file's short name.The FILE_NAME_INFORMATION data element is as follows. |
| FileStandardInformation | This information class is used to query or set file information.The FILE_STANDARD_INFORMATION data element is as follows. |
| FileStreamInformation | This information class is used to enumerate the streams for a file. The FILE_STREAM_INFORMATION data element is as follows. |
| FileValidDataLengthInformation | This information class is used to set the valid data length information for a file. The FILE_VALID_DATA_LENGTH_INFORMATION data element is as follows. |
| FsccFileFullEaInformation | |
| GenericReparseBuffer | The Generic Reparse Data Buffer data element is as follows. |
| HASH_HEADER | All hash files storing a hash BLOB MUST start from a valid format HASH_HEADER as follows. The format is valid only for the SMB 2.1 dialect. |
| IOCTL_Request | The SMB2 IOCTL Request packet is sent by a client to issue an implementation-specific file system control or device control (FSCTL/IOCTL) command across the network. For a list of IOCTL operations, see section and [MS-FSCC] section 2.3.This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| IOCTL_Response | The SMB2 IOCTL Response packet is sent by the server to transmit the results of a client SMB2 IOCTL request. This response consists of an SMB2 header, as specified in section , followed by this response structure: |
| LEASE_BREAK_Acknowledgment | The SMB2 Lease Break Acknowledgment packet is sent by the client in response to an SMB2 Lease Break Notification packet sent by the server. This request is valid only in the SMB 2.1 dialect. The server responds to a lease break acknowledgment with an SMB2 Lease Break Response. |
| LEASE_BREAK_Notification_Packet | The SMB2 Lease Break Notification packet is sent by the server when the underlying object store indicates that a lease is being broken, representing a change in the lease state. This is only valid on the SMB 2.1 dialect. This response is composed of an SMB2 header, as specified in section 2.2.1, followed by this notification structure: |
| LEASE_BREAK_Response | The SMB2 Lease Break Acknowledgment packet is sent by the client in response to an SMB2 Lease Break Notification packet sent by the server. This request is valid only in the SMB 2.1 dialect. The server responds to a lease break acknowledgment with an SMB2 Lease Break Response. |
| LOCK_ELEMENT | The SMB2 LOCK_ELEMENT Structure packet is used by the SMB2 LOCK Request packet to indicate segments of files that should be locked or unlocked. |
| LOCK_Request | The SMB2 LOCK Request packet is sent by the client to either lock or unlock portions of a file. Several different segments of the file can be affected with a single SMB2 LOCK Request packet, but they all must be within the same file. |
| LOCK_Response | The SMB2 LOCK Response packet is sent by a server in response to an SMB2 LOCK Request packet. This response is composed of an SMB2 header, as specified in section , followed by this request structure: |
| LOGOFF_Request | The SMB2 LOGOFF Request packet. |
| LOGOFF_Response | The SMB2 LOGOFF Response packet is sent by the server to confirm that an SMB2 LOGOFF Request was completed successfully. This response is composed of an SMB2 header, as specified in section , followed by this request structure: |
| MountPointReparseBuffer | The Mount Point Reparse Data Buffer data element, which contains information on mount point reparse points, is as follows. |
| NEGOTIATE_Request | |
| NEGOTIATE_Response | |
| NETWORK_INTERFACE_INFO_Response | The NETWORK_INTERFACE_INFO is returned to the client by the server in an SMB2 IOCTL response for FSCTL_QUERY_NETWORK_INTERFACE_INFO request. |
| NETWORK_INTERFACE_INFO_Response_SockAddr_Storage | The SockAddr_Storage of NETWORK_INTERFACE_INFO_Response Refer to http://go.microsoft.com/fwlink/?LinkId=231819 |
| NETWORK_RESILIENCY_Request | NETWORK_RESILIENCY_Request |
| NTFS_VOLUME_DATA_BUFFER | The FSCTL_GET_NTFS_VOLUME_DATA reply message returns the results of the FSCTL_GET_NTFS_VOLUME_DATA request as an NTFS_VOLUME_DATA_BUFFER element. The NTFS_VOLUME_DATA_BUFFER contains information on a volume. For more information on the NTFS file system, see [MSFT-NTFS]. |
| OPLOCK_BREAK_Acknowledgment | The SMB2 OPLOCK_BREAK Acknowledgment packet is sent by the client in response to an SMB2 OPLOCK_BREAK notification packet sent by the server. The server responds to an oplock break acknowledgment with an SMB2 OPLOCK_BREAK response. The client MUST NOT send an oplock break acknowledgment for an oplock break from level II to none. A break from level II MUST always transition to none. Thus, the client does not have to send a request to the server because there is no question how the transition was made. |
| OPLOCK_BREAK_Notification_Packet | The SMB2 OPLOCK_BREAK Notification Packet is sent by the server when the underlying object store indicates that an opportunistic lock (oplock) is being broken, representing a change in the oplock level. This response is composed of an SMB2 header, as specified in section , followed by this notification structure: |
| OPLOCK_BREAK_Response | The SMB2 OPLOCK_BREAK Response packet is sent by the server in response to an oplock break acknowledgment from the client. This response is composed of an SMB2 header, as specified in section , followed by this response structure: |
| Packet_Header | The SMB2 Packet Header - SYNC packet is the header of all SMB 2.0 Protocol packets. If the SMB2_FLAGS_ASYNC_COMMAND is not set in Flags, the header takes the following form: |
| Packet_Header_ASync | The SMB2 Packet Header packet is the header of all SMB 2.0 Protocol packets. If the SMB2_FLAGS_ASYNC_COMMAND is set in Flags, the header takes the following form: |
| QUERY_DIRECTORY_Request | The SMB2 QUERY_DIRECTORY Request packet is sent by the client to obtain a directory enumeration on an open directory handle. This request consists of an SMB2 header, as specified in section , followed by this request structure: |
| QUERY_DIRECTORY_Response | The SMB2 QUERY_DIRECTORY Response packet is sent by a server in response to an SMB2 QUERY_DIRECTORY Request. This response consists of an SMB2 header, as specified in section , followed by this response structure: |
| QUERY_INFO_Request | The SMB2 QUERY_INFO Request packet is sent by a client to request information on a file, named pipe, or underlying volume. This request consists of an SMB2 header, as specified in section , followed by this request structure: |
| QUERY_INFO_Response | The SMB2 QUERY_INFO Response packet is sent by the server in response to an SMB2 QUERY_INFO Request packet. This response consists of an SMB2 header, as specified in section , followed by this response structure: |
| QUERY_QUOTA_INFO | The SMB2 QUERY_QUOTA_INFO packet that specifies the quota information to return. |
| READ_Request | The SMB2 READ Request packet is sent by the client to request a read operation on the file that is specified by the FileId. This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| READ_Response | The SMB2 READ Response packet is sent in response to an SMB2 READ Request packet. This response is composed of an SMB2 header, as specified in section , followed by this response structure: |
| REPARSE_GUID_DATA_BUFFER | The REPARSE_GUID_DATA_BUFFER data element MUST be used by all non-Microsoft file systems, filters, and minifilters to store data for a reparse point. Each reparse point contains one REPARSE_GUID_DATA_BUFFER structure.Reparse point tags are assigned to independent software vendors (ISVs) by Microsoft. Reparse point GUIDs are assigned by the ISV. An ISV MUST associate one GUID to each assigned reparse point tag, and MUST always use that GUID with that tag.For more information on reparse points, see [REPARSE].If the high bit of the ReparseTag element is 0, an application MUST interpret the reparse point data as a REPARSE_GUID_DATA_BUFFER; otherwise, it MUST be interpreted as a REPARSE_DATA_BUFFER.Each reparse point MUST contain one REPARSE_GUID_DATA_BUFFER structure. The REPARSE_GUID_DATA_BUFFER data element is as follows. |
| SESSION_SETUP_Request | The SMB2 SESSION_SETUP Request packet is sent by the client to request a new authenticated session within a new or existing SMB 2.0 Protocol transport connection to the server. This request is composed of an SMB 2.0 Protocol header as specified in section followed by this request structure: |
| SESSION_SETUP_Response | The SMB2 SESSION_SETUP Response packet is sent by the server in response to an SMB2 SESSION_SETUP Request packet. This response is composed of an SMB 2.0 Protocol header, as specified in section , that is followed by this response structure: |
| SET_INFO_Request | The SMB2 SET_INFO Request packet is sent by a client to set information on a file or underlying file system. This request consists of an SMB2 header, as specified in section , followed by this request structure: |
| SET_INFO_Response | The SMB2 SET_INFO Response packet is sent by the server in response to an SMB2 SET_INFO Request to notify the client that its request has been successfully processed. This response consists of an SMB2 header, as specified in section , followed by this response structure: |
| SMB2_ENCRYPTION_CAPABILITIES | The SMB2_ENCRYPTION_CAPABILITIES context is specified in an SMB2 NEGOTIATE request by the client to indicate which encryption algorithms the client supports. |
| SMB2_NEGOTIATE_CONTEXT_Header | The SMB2_NEGOTIATE_CONTEXT structure is used by the SMB2 NEGOTIATE Request and the SMB2 NEGOTIATE Response to encode additional properties. |
| SMB2_PREAUTH_INTEGRITY_CAPABILITIES | The SMB2_PREAUTH_INTEGRITY_CAPABILITIES context is specified in an SMB2 NEGOTIATE request by the client to indicate which preauthentication integrity hash algorithms the client supports and to optionally supply a preauthentication integrity hash salt value. |
| SRV_COPYCHUNK | The SRV_COPYCHUNK packet is sent in a SRV_COPYCHUNK_COPY packet by the client to initiate a server-side copy of data to describe an individual data range to copy. It is set as the contents of the input data buffer. This packet consists of the following: |
| SRV_COPYCHUNK_COPY | The SRV_COPYCHUNK_COPY packet is sent in an SMB2 IOCTL Request by the client to initiate a server-side copy of data. It is set as the contents of the input data buffer. This packet consists of the following: |
| SRV_COPYCHUNK_RESPONSE | The SRV_COPYCHUNK_RESPONSE packet is sent in an SMB2 IOCTL Response by the server to return the results of a server-side copy operation. It is placed in the Buffer field of the SMB2 IOCTL Response packet. This packet consists of the following: |
| SRV_HASH_RETRIEVE_FILE_BASED | The SRV_READ_HASH response is returned to the client by the server in an SMB2 IOCTL Response for the FSCTL_SRV_READ_HASH request. This structure is placed in the Buffer field in the SMB2 IOCTL Response, and the OutputOffset and OutputCount fields MUST be updated to describe the buffer as specified in section 2.2.32. The SRV_READ_HASH response MUST be formatted as follows: |
| SRV_HASH_RETRIEVE_HASH_BASED | The SRV_READ_HASH response is returned to the client by the server in an SMB2 IOCTL Response for the FSCTL_SRV_READ_HASH request. This structure is placed in the Buffer field in the SMB2 IOCTL Response, and the OutputOffset and OutputCount fields MUST be updated to describe the buffer as specified in section 2.2.32. The SRV_READ_HASH response MUST be formatted as follows: |
| SRV_READ_HASH_Request | The REQUEST_HASH_DATA packet is sent to the server by the client in an SMB2 IOCTL Request SRV_READ_HASH to retrieve the hash blob for a specified file. The request is valid only for the SMB 2.1 dialect. It is set as the contents of the input data buffer. This packet consists of the following: |
| SRV_REQUEST_RESUME_KEY_Response | The SRV_REQUEST_RESUME_KEY packet is returned to the client by the server in an SMB2 IOCTL Response for the FSCTL_SRV_REQUEST_RESUME_KEY request. This SRV_REQUEST_RESUME_KEY is placed in the Buffer field in the SMB2 IOCTL Response, and the OutputOffset and OutputCount fields MUST be updated to describe the buffer as specified in section 2.2.32. This packet consists of the following: |
| SRV_SNAPSHOT_ARRAY | The SRV_SNAPSHOT_ARRAY packet is returned to the client by the server in an SMB2 IOCTL Response for the FSCTL_SRV_ENUMERATE_SNAPSHOTS request, as specified in [MS-SMB] section 2.2.14.7.1. This packet MUST contain all the revision time-stamps that are associated with the particular open. This SRV_SNAPSHOT_ARRAY is placed in the OutputBuffer field in the SMB2 IOCTL Response. This packet consists of the following: |
| SVHDX_OPEN_DEVICE_CONTEXT | The SVHDX_OPEN_DEVICE_CONTEXT packet is sent by the client to open the shared virtual disk. |
| SVHDX_OPEN_DEVICE_CONTEXT_V2 | The SVHDX_OPEN_DEVICE_CONTEXT_V2 packet is sent by the client to open the shared virtual disk. |
| Smb2DummyStatus | |
| Smb2Status | the Status of Smb2Packet. they are get from [MS-ERREF]. |
| SymbolicLinkReparseBuffer | The Symbolic Link Reparse Data Buffer data element, which contains information on symbolic link reparse points, is as follows. |
| Symbolic_Link_Error_Response | The Symbolic Link Error Response is used to describe the target path that the client MUST follow when a symbolic link is encountered on create. This structure is contained in the ErrorData section of the SMB2 ERROR Response. This structure MUST NOT be returned in an SMB2 ERROR Response unless the Status code in the header of that response is set to STATUS_STOPPED_ON_SYMLINK. The structure has the following format: |
| TARGET_LINK_TRACKING_INFORMATION_Buffer | The TARGET_LINK_TRACKING_INFORMATION_Buffer data element is as follows. |
| TREE_CONNECT_Request | |
| TREE_CONNECT_Response | The SMB2 TREE_CONNECT Response packet is sent by the server when an SMB2 TREE_CONNECT request is processed successfully by the server. The server MUST set the TreeId of the newly created tree connect in the SMB 2.0 Protocol header of the response. This response is composed of an SMB2 Packet Header that is followed by this response structure: |
| TREE_DISCONNECT_Request | The SMB2 TREE_DISCONNECT Request packet is sent by the client to request that the tree connect that is specified in the TreeId within the SMB2 header be disconnected. This request is composed of an SMB2 header, as specified in section , that is followed by this variable-length request structure: |
| TREE_DISCONNECT_Response | The SMB2 TREE_DISCONNECT Response packet is sent by the server to confirm that an SMB2 TREE_DISCONNECT Request was successfully processed. This response is composed of an SMB2 header, as specified in section , that is followed by this request structure: |
| Transform_Header | |
| VALIDATE_NEGOTIATE_INFO_Request | The VALIDATE_NEGOTIATE_INFO request packet is sent to the server by the client in an SMB2 IOCTL Request FSCTL_VALIDATE_NEGOTIATE_INFO to request validation of a previous SMB2 NEGOTIATE. |
| VALIDATE_NEGOTIATE_INFO_Response | The VALIDATE_NEGOTIATE_INFO response is returned to the client by the server in an SMB2 IOCTL response for FSCTL_VALIDATE_NEGOTIATE_INFO request. |
| WRITE_Request | The SMB2 WRITE Request packet is sent by the client to write data to the file or named pipe on the server. This request is composed of an SMB2 header, as specified in section , followed by this request structure: |
| WRITE_Response | The SMB2 WRITE Response packet is sent by the server to write data to the file or named pipe on the server. This response is composed of an SMB2 header, as specified in section , followed by this response structure: |
| _ACCESS_MASK | An ACCESS_MASK is a 32-bit set of flags that are used to encode the user rights to an object. An access mask is used both for encoding the rights to an object assigned to a principal and for encoding the desired access when opening an object. The lower 16 bits are used for object-specific user rights. A file object would encode, for example, Read Access, Write Access, and so forth. A registry key object would encode Create Subkey, Read Value, etc.The upper 16 bits are user rights that are common to all objects, or are generic rights that can be mapped to object-specific user rights by the object itself. |
| _FILETIME | The FILETIME structure is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since January 1, 1601, in Coordinated Universal Time (UTC) format. |
