Compartir a través de

6 Appendix A: Product Behavior

  • Artículo

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows NT Server 3.51 operating system

  • Windows NT Server 4.0 operating system

  • Windows NT Workstation 4.0 operating system

  • Windows 98 operating system

  • Windows 98 operating system Second Edition

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.1: On Windows, SMB transports are supported as TDI Transport Drivers, as described in [MSDN-TrnspDrvIntfc].

<2> Section 2.1.1: On MS-DOS, OS/2, and Windows systems, NetBIOS presents a common API. The CIFS implementations on these platforms are written to use the NetBIOS API, which makes it possible to interchange NetBIOS-based transports without modifying the CIFS implementation itself. Implementation of the NetBIOS API is not necessary for CIFS interoperability.

<3> Section 2.1.1: Windows NT Server operating system drops the transport connection and does not return an error message response with an SMB error class of ERRCMD (0xFF).

<4> Section 2.1.1.2: The Windows NT operating system implementation of the NetBIOS Name Service for NBT is known as the Windows Internet Name Service (WINS). The Windows NT implementation of the NetBIOS Name Server (NBNS) is known as a WINS server.

Microsoft's implementation of NBT for Windows NT and Windows 98 diverges from the standard specified in [RFC1001] and [RFC1002]. There are several modifications and additions to the prescribed behavior of the name service, and the implementation of the datagram service is incomplete. See [IMPCIFS] for a discussion of some of these variations. Windows-specific extensions to NBT are documented in [MS-NBTE].

<5> Section 2.1.2: Direct TCP Transport is probably the best-known example of direct hosting. Direct TCP Transport is described in [MS-SMB]. CIFS does not support Direct TCP Transport, because it was developed for Windows 2000 operating system and is not supported on Windows NT or Windows 98.

<6> Section 2.1.2.1: The recommended maximum interval between SMB requests is four (4) minutes. Windows NT Server 4.0 has a default time-out value of 15 minutes.

<7> Section 2.1.3: Windows NT Server 4.0 always sends a zero value for SessionKey.

<8> Section 2.1.3: Windows-based CIFS servers set MaxNumberVcs in the server's SMB_COM_NEGOTIATE response to 0x0001, but do not enforce this limit. This allows a CIFS client to establish more virtual circuits than allowed by this value.

<9> Section 2.1.3: Windows NT Server does disconnect all existing transport-level connections from a client when it receives a new SMB_COM_SESSION_SETUP_ANDX request from that client with a VcNumber value of zero.

<10> Section 2.2.1.1.3: CIFS wildcard characters are based on Windows wildcard characters, as described in [MS-FSA] section 2.1.4.4, Algorithm for Determining if a FileName Is in an Expression. For more information on wildcard behavior in Windows, see [FSBO] section 7.

<11> Section 2.2.1.2.1.1: Windows clients include both the size of the SizeOfListInBytes field and the total size of the GEAList field when calculating the value passed in the SizeOfListInBytes field for compatibility with dialects less than the LAN Manager 1.2 dialect, as implemented in OS/2 v1.2. See [XOPEN-SMB] sections 4.3.7 and 16.1.5 for more information.

<12> Section 2.2.1.2.2: The SMB_FEA (section 2.2.1.2.2) structure originated with the LANMAN1.2 dialect and is, therefore, used in Trans2 calls, the majority of which also originated in the LANMAN1.2 dialect. See [XOPEN-SMB] section 16.1.5 for a detailed description of the SMB_FEA structure. NT_TRANSACT_CREATE makes use of the FILE_FULL_EA_INFORMATION structure, which is similar to SMB_FEA. See [MS-FSCC] for information on the FILE_FULL_EA_INFORMATION structure.

<13> Section 2.2.1.2.2.1: Windows clients include both the size of the SizeOfListInBytes field and the total size of the FEAList field when calculating the value passed in the SizeOfListInBytes field. This is required for compatibility with dialects less than the LAN Manager 1.2 dialect, as implemented in OS/2 v1.2. See [XOPEN-SMB] sections 4.3.7 and 16.1.5 for more information.

<14> Section 2.2.1.2.3: The file attributes encoded in the SMB_EXT_FILE_ATTR (section 2.2.1.2.3) data type are based on the native Windows file attributes described in [MS-FSCC] section 2.6 and listed in [MSDN-CreateFile]. The following table provides a mapping between the file attributes presented in this document and those in [MS-FSCC], as well as unsupported values and values unique to this document.

Name or Status in [MS-CIFS]

Name or Status in [MS-FSCC]

ATTR_READONLY

FILE_ATTRIBUTE_READONLY

ATTR_HIDDEN

FILE_ATTRIBUTE_HIDDEN

ATTR_SYSTEM

FILE_ATTRIBUTE_SYSTEM

ATTR_DIRECTORY

FILE_ATTRIBUTE_DIRECTORY

ATTR_ARCHIVE

FILE_ATTRIBUTE_ARCHIVE

ATTR_NORMAL

FILE_ATTRIBUTE_NORMAL

ATTR_TEMPORARY

FILE_ATTRIBUTE_TEMPORARY

Not Supported in CIFS

FILE_ATTRIBUTE_SPARSE_FILE

Not Supported in CIFS

FILE_ATTRIBUTE_REPARSE_POINT

ATTR_COMPRESSED

FILE_ATTRIBUTE_COMPRESSED

Not Supported in CIFS

FILE_ATTRIBUTE_OFFLINE

Not Supported in CIFS

FILE_ATTRIBUTE_NOT_CONTENT_INDEXED

Not Supported in CIFS

FILE_ATTRIBUTE_ENCRYPTED

POSIX_SEMANTICS

Unique to CIFS/SMB

BACKUP_SEMANTICS

Unique to CIFS/SMB

DELETE_ON_CLOSE

Unique to CIFS/SMB

SEQUENTIAL_SCAN

Unique to CIFS/SMB

RANDOM_ACCESS

Unique to CIFS/SMB

NO_BUFFERING

Unique to CIFS/SMB

WRITE_THROUGH

Unique to CIFS/SMB

<15> Section 2.2.1.2.3: Use care when using this option because files created with this flag might not be accessible by applications written for MS-DOS, Windows 3.0 operating system, Windows NT 3.1 operating system, or Windows NT.

<16> Section 2.2.1.2.3: Windows uses this flag to optimize file caching. If an application moves the file pointer for random access, optimum caching might not occur; however, correct operation is still guaranteed. Specifying this flag can increase performance for applications that read large files using sequential access. Performance gains can be even more noticeable for applications that read large files mostly sequentially, but occasionally skip over small ranges of bytes.

<17> Section 2.2.1.4.1: The maximum value permitted in the SMB_DATE.YEAR field is 119, resulting in a year range of 1980 to 2099.

<18> Section 2.2.1.5: Windows NT Server identifies these error codes as 32-bit values by leaving the SMB_FLAGS2_NT_STATUS bit set in the response to a request that also had the SMB_FLAGS2_NT_STATUS bit set.

<19> Section 2.2.1.6: Windows-based clients set the PID to the process identifier of the actual calling process for the following commands. For all other commands, Windows-based clients set the PID value to 0x0000FEFF.

  • SMB_COM_NT_CREATE_ANDX (0xA2)

  • SMB_COM_OPEN_PRINT_FILE (0xC0)

  • All subcommands of SMB_COM_TRANSACTION (0x25) and SMB_COM_TRANSACTION_SECONDARY (0x26) except TRANS_MAILSLOT_WRITE, if Client.Connection.ServerCapabilities includes CAP_NT_SMBS.

  • All subcommands of SMB_COM_TRANSACTION2 (0x32) and SMB_COM_TRANSACTION2_SECONDARY (0x33), if Client.Connection.ServerCapabilities includes CAP_NT_SMBS.

<20> Section 2.2.1.6.6: Windows NT Server always returns 0x00000000 and ignores the SessionKey when it is sent by the client in an SMB_COM_SESSION_SETUP_ANDX Request (section 2.2.4.53.1).

<21> Section 2.2.1.6.8: Windows NT Server uses this value internally as part of its list management mechanism.

<22> Section 2.2.2.3.3: Windows NT always returns this string in Unicode-encoded format.

<23> Section 2.2.2.4: Windows NT Server returns this error code if at least one command parameter fails validation tests such as a field value being out of range or fields within a command being internally inconsistent.

<24> Section 2.2.2.4: This error code is defined as ERRinvtid in Windows 98. Windows NT uses a completely different naming style.

<25> Section 2.2.2.4: Windows NT Server defines this class but does not return it. Windows NT client does not test for the ERRCMD class. In many instances, Windows-based servers close transport level connections if the incoming messages cannot be parsed.

<26> Section 2.2.3.1: This bit is ignored by Windows systems, which always handle pathnames as case-insensitive.

<27> Section 2.2.3.1: If CAP_STATUS32 has been negotiated during the SMB connection, Windows-based servers ignore the value of the SMB_FLAGS2_NT_STATUS bit in client requests. If the Status field value to be returned in the header is STATUS_SUCCESS, Windows-based servers copy the value of the SMB_FLAGS2_NT_STATUS bit from the client request into the server response.

If CAP_STATUS32 has been negotiated and an error is returned and SMB_FLAGS2_NT_STATUS is not set in the request, the value of the SMB_FLAGS2_NT_STATUS bit and the format of the Status field in the header in the server response is undefined.

<28> Section 2.2.4.3.1: Windows NT Server always ignores the SearchAttributes field on Open and Create operations, and searches for files by name only.

<29> Section 2.2.4.15.2: Windows NT server temporary file names begin with "SRV" and are followed by the character equivalents of five (5) random hexadecimal digits (0-F). There is no extension set for the file name. The client is responsible for deleting the temporary file when it is no longer needed.

<30> Section 2.2.4.19.1: Windows NT server behavior is determined by the negotiated protocol dialect. Clients that negotiate Core Protocol can use a negative value in the Offset field to position the file pointer to the beginning of the file (BOF). Clients negotiating other protocol dialects receive an error if they supply a negative value in the Offset field.

<31> Section 2.2.4.19.2: Windows NT does not check for overflow conditions. It allows the file pointer that is maintained by the server to "wrap around".

<32> Section 2.2.4.23: Windows NT clients and Windows NT servers support this command on connection-oriented transports. This command does not support named pipes or I/O devices.

Windows does not support the Timeout field.

<33> Section 2.2.4.24: Windows NT servers return STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd).

<34> Section 2.2.4.25.2: Windows NT servers always set Available to 0xFFFF.

<35> Section 2.2.4.26: Windows systems support this command only over connectionless transports. Consequently, Windows 98 and Windows NT clients and all clients connected to Windows NT servers set the 0x08 bit of the WriteMode field in the request. Windows NT servers support Write MPX only to regular files or spooled printer files. This command does not support writing to named pipes or I/O devices.

The Timeout field is not supported.

<36> Section 2.2.4.26.1: The Timeout field was used in earlier dialects. In the NT LAN Manager dialect, Write MPX is not used to write to named pipes or devices, so the Timeout field is ignored.

<37> Section 2.2.4.27: Windows NT servers return STATUS_INVALID_SMB (ERRSRV/ERRerror) instead of STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc).

<38> Section 2.2.4.29: Windows NT Server returns  STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd) instead of STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc) if the WordCount field in the request is set to 1; otherwise, Windows NT Server returns STATUS_INVALID_SMB (ERRSRV/ERRerror).

<39> Section 2.2.4.32.1: Windows NT Server does not support the CHANGE_LOCKTYPE flag of TypeOfLock. A client requesting that the server atomically change the lock type from a shared lock to an exclusive lock or vice versa results in an error being returned to the client.

<40> Section 2.2.4.32.1: If the CANCEL_LOCK bit is set, Windows NT servers cancel only the first lock request range listed in the lock array.

<41> Section 2.2.4.33.1: One way transactions are used only when communicating with Mailslots, which means that they never occur within CIFS sessions.

<42> Section 2.2.4.33.1: Windows NT Server honors the Timeout field only in transaction subcommands that specifically state that the Timeout field is honored. Check the individual subcommands for details.

<43> Section 2.2.4.33.1: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<44> Section 2.2.4.33.1: Windows always sets DataCount to a value of ParameterCount + ParameterOffset. This restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<45> Section 2.2.4.33.2: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<46> Section 2.2.4.33.2: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This action restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<47> Section 2.2.4.34.1: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<48> Section 2.2.4.34.1: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<49> Section 2.2.4.35: Windows NT server does not implement SMB_COM_IOCTL_SECONDARY. Therefore, all of the parameters and data for a request has to fit within the MaxBufferSize that was established during session setup. Windows NT server does not honor the value supplied in the Timeout field. Windows NT implementation specifics follow.

Category

Function

Parameters

Data

Description

SERIAL_DEVICE

0x0001

GET_BAUD_RATE

0x0061

None

USHORT BaudRate

Get the baud rate on the serial device.

SET_BAUD_RATE

0x0041

None

USHORT BaudRate

Set the baud rate on the serial device

GET_LINE_CONTROL

0x0062

UCHAR DataBits;

UCHAR Parity;

UCHAR StopBits;

UCHAR TransBreak;

None.

Get serial device line control information.

SET_LINE_CONTROL

0x0042

UCHAR DataBits;

UCHAR Parity;

UCHAR StopBits;

UCHAR TransBreak;

None.

Set serial device line control information.

GET_DCB_INFORMATION

0x0073

None.

USHORT WriteTimeout;

USHORT ReadTimeout;

UCHAR ControlHandShake;

UCHAR FlowReplace;

UCHAR Timeout;

UCHAR ErrorReplacementChar;

UCHAR BreakReplacementChar;

UCHAR XonChar;

UCHAR XoffChar;

Get serial device device control information.

SET_DCB_INFORMATION

0x0053

None.

USHORT WriteTimeout;

USHORT ReadTimeout;

UCHAR ControlHandShake;

UCHAR FlowReplace;

UCHAR Timeout;

UCHAR ErrorReplacementChar;

UCHAR BreakReplacementChar;

UCHAR XonChar;

UCHAR XoffChar;

Get serial device device control information.

GET_COMM_ERROR

0x006D

None.

USHORT Error;

Get serial device device error information.

SET_TRANSMIT_TIMEOUT

0x0044

Not implemented.

SET_BREAK_OFF

0x0045

Not implemented.

SET_MODEM_CONTROL

0x0046

Not implemented.

SET_BREAK_ON

0x004B

Not implemented.

STOP_TRANSMIT

0x0047

Not implemented.

START_TRANSMIT

0x0048

Not implemented.

GET_COMM_STATUS

0x0064

Not implemented.

GET_LINE_STATUS

0x0065

Not implemented.

GET_MODEM_OUTPUT

0x0066

Not implemented.

GET_MODEM_INPUT

0x0067

Not implemented.

GET_INQUEUE_COUNT

0x0068

Not implemented.

GET_OUTQUEUE_COUNT

0x0069

Not implemented.

GET_COMM_EVENT

0x0072

Not implemented.

PRNTER_DEVICE

0x0005

GET_PRINTER_STATUS

0x0066

CHAR Status

Always returns OS2_STATUS_PRINTER_HAPPY (0x90).

SPOOLER_DEVICE

0x0053

GET_PRINTER_ID

0x0060

USHORT JobId;

UCHAR Buffer[1];

Print job ID and printer share name.

GENERAL_DEVICE

0x000B

Not implemented.

<50> Section 2.2.4.35.2: [XOPEN-SMB], in section 14.3, states that ERRSRV/ERRnosupport can be returned if the server does not support the SMB_COM_IOCTL command. Windows NT servers support this command, although it is deprecated.

<51> Section 2.2.4.37: Windows NT servers attempt to process this command, but the implementation is incomplete and the results are not predictable.

<52> Section 2.2.4.38: Windows NT servers attempt to process this command, but the implementation is incomplete and the results are not predictable.

<53> Section 2.2.4.39.1: Windows 98 accept only an SMB_COM_ECHO request containing a valid TID or a TID value of 0xFFFF (-1). Windows NT ignores the TID in the SMB_COM_ECHO request.

<54> Section 2.2.4.39.2: Windows clients ignore the SequenceNumber field in the server response.

<55> Section 2.2.4.40: Windows NT and Windows 98 clients do not send SMB_COM_WRITE_AND_CLOSE (0x2C) (section 2.2.4.40) requests.

<56> Section 2.2.4.40.2: Windows NT Server appends three null padding bytes to this message, following the ByteCount field. These three bytes are not message data and can safely be discarded.

<57> Section 2.2.4.41.1: Windows NT Server ignores SearchAttrs in open requests.

<58> Section 2.2.4.42.2: An AndX chain can be formed by adding an SMB_COM_CLOSE command as a follow-on to SMB_COM_READ_ANDX. SMB_COM_CLOSE is the only valid follow-on command for SMB_COM_READ_ANDX. Windows NT Server correctly processes AndX chains consisting of SMB_COM_READ_ANDX and SMB_COM_CLOSE, but does not correctly set the AndXCommand field in the response message. Windows NT Server always sets the value of AndXCommand in the SMB_COM_READ_ANDX response to SMB_COM_NO_ANDX_COMMAND (0xFF).

<59> Section 2.2.4.42.2: Windows NT Server always sets this field in this message to zero, even if there is a chained SMB_COM_CLOSE follow-on response connected to the SMB_COM_READ_ANDX response message. If present, the SMB_COM_CLOSE response can be seen as three null padding bytes (representing WordCount==0x00 and ByteCount==0x0000) immediately following the SMB_Parameters of the SMB_COM_READ_ANDX portion of the message.

<60> Section 2.2.4.42.2: Windows-based servers set the DataLength field to 0x0000 and return STATUS_SUCCESS.

<61> Section 2.2.4.43.1: Windows NT and Windows 98 clients set this field to zero for non-message mode pipe writes. This field is ignored by the server if the FID indicates a file. If a pipe write spans multiple requests, for all pipe write requests Windows clients set this field to the total number of bytes to be written.

<62> Section 2.2.4.43.2: Windows NT servers always set Available to 0xFFFF.

<63> Section 2.2.4.44: Windows NT Server returns STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd) if the WordCount field in the request is set to 3; otherwise, Windows NT Server returns STATUS_INVALID_SMB (ERRSRV/ERRerror).

<64> Section 2.2.4.45: Windows NT Server has a partial implementation that treats this SMB command as though it were an SMB_COM_CLOSE (section 2.2.4.5) followed by an SMB_COM_TREE_DISCONNECT (section 2.2.4.51); however, the SMB_COM_TREE_DISCONNECT is never called. The format of the command is identical to that of SMB_COM_CLOSE. This command was never documented and is not called by Windows clients.

<65> Section 2.2.4.46.1: One way transactions are used only when communicating with Mailslots, which means that they never occur within CIFS sessions.

<66> Section 2.2.4.46.1: Windows NT Server honors the Timeout field only in transaction subcommands that specifically state that the Timeout field is honored. Check the individual subcommands for details.

<67> Section 2.2.4.46.1: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<68> Section 2.2.4.46.1: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<69> Section 2.2.4.46.2: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<70> Section 2.2.4.46.2: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This action restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<71> Section 2.2.4.46.2: Windows NT Server sends an arbitrary number of additional bytes beyond the end of the SMB response message. These additional bytes can be ignored by the recipient.

<72> Section 2.2.4.47.1: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<73> Section 2.2.4.47.1: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This action restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<74> Section 2.2.4.50.1: Windows NT servers do not test to determine whether the strings in this request are 16-bit Unicode or 8-bit extended ASCII. It assumes that they are 8-bit strings. Clients that support Unicode use the SMB_COM_TREE_CONNECT_ANDX (section 2.2.4.55) command.

<75> Section 2.2.4.52.1: Windows 98 and Windows NT clients typically send a TID value of zero (0x0000) in the SMB_COM_NEGOTIATE request. This value has no particular significance.

<76> Section 2.2.4.52.1: Windows 98 and Windows NT clients typically send a UID value of zero (0x0000) in the SMB_COM_NEGOTIATE request. This value has no particular significance.

<77> Section 2.2.4.52.2: The name of this bit value is misleading. Encrypted passwords are used to generate the response to the challenge, but are not sent across the network.

<78> Section 2.2.4.52.2: In some implementations of earlier dialects, this bit was used to indicate support for the SMB_COM_SECURITY_PACKAGE_ANDX command. That usage is obsolete.

<79> Section 2.2.4.52.2: On Windows NT server the default value is 50 (0x0032). This value can be set using the MaxMpxCt registry key.

<80> Section 2.2.4.52.2: Windows-based CIFS servers set this field to 0x0001, but do not enforce this limit. This allows a CIFS client to establish more virtual circuits than allowed by this value. Because this limit is not enforced on Windows, CIFS clients can ignore this limit and attempt to establish more than the number of virtual circuits allowed by this value. The Windows behavior of the CIFS server allows a client to exceed this limit, but other server implementations can enforce this limit and not allow this to occur. Windows clients ignore the MaxNumberVcs field in the server response.

<81> Section 2.2.4.52.2: If more than 512 MB of memory is available, by default, Windows NT Server, Windows 2000, Windows Server 2003 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Server 2012 operating system, and Windows Server 2012 R2 operating system set the MaxBufferSize  value to 16644 bytes. The MaxBufferSize is configurable as described in [MSKB-320829].

<82> Section 2.2.4.52.2: Windows clients ignore the MaxRawSize field in the server response and use a default value of 65536 bytes (64K) as the maximum raw buffer size for an SMB_COM_WRITE_RAW Request (section 2.2.4.25.1).

<83> Section 2.2.4.52.2: Windows NT clients assume that CAP_NT_FIND is set if CAP_NT_SMBS is set.

<84> Section 2.2.4.52.2: The CAP_BULK_TRANSFER capability was supposed to indicate server support for the SMB_COM_READ_BULK and SMB_COM_WRITE_BULK commands, which were never implemented. The CAP_BULK_TRANSFER capability bit was never used in Windows-based clients or servers.

<85> Section 2.2.4.52.2: The CAP_COMPRESSED_DATA capability bit was supposed to indicate whether a server supported compressed SMB packets. This feature was never specified, implemented, or used. Windows-based clients and servers do not support CAP_COMPRESSED_DATA, so this capability is never set.

<86> Section 2.2.4.52.2: The CAP_QUADWORD_ALIGNED capability bit was intended to indicate that Windows directory InformationLevel responses were quadword-aligned. The CAP_QUADWORD_ALIGNED capability bit was never used in released Windows-based clients or servers.

<87> Section 2.2.4.52.2: Windows clients ignore the SystemTime field in the server response.

<88> Section 2.2.4.52.2: Windows clients ignore the ServerTimeZone field in the server response.

<89> Section 2.2.4.52.2: Windows NT servers always send the DomainName field in Unicode characters and never add a padding byte for alignment. Windows clients ignore the DomainName field in the server response.

<90> Section 2.2.4.53: Windows clients always issue SMB_COM_SESSION_SETUP_ANDX and SMB_COM_TREE_CONNECT_ANDX as a batched request.

<91> Section 2.2.4.53.1: Windows NT clients and servers always use a MaxBufferSize value that is a multiple of four (4). MaxBufferSize values, sent or received via SMB, are always rounded down to the nearest multiple of four before they are used. This is done by masking out the two lowest-order bits of the value: MaxBufferSize &= ~3;

The default MaxBufferSize on Windows clients is 4356 (0x1104) bytes (4KB + 260Bytes). The MaxBufferSize can be configured through the following registry setting:

 HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizReqBuf

If the client's MaxBufferSize value in a session setup request is below a system-specified minimum value, Windows CIFS servers will fail the request and return ERRSRV/ERRerror. The default minimum acceptable MaxBufferSize value is 500 (0x1F4) bytes. This value can be modified using the following registry setting:

 HKEY_Local_Machine\System\CurrentControlSet\Services\LanManServer\Parameters\MinClientBufferSize

<92> Section 2.2.4.53.1: Windows-based servers support a maximum SMB_COM_READ_ANDX (section 2.2.4.42) buffer size of 61440 (0xF000 = 60K) when the CAP_LARGE_READX capability is negotiated.

<93> Section 2.2.4.53.1: Windows-based CIFS servers set a limit for the MaxNumberVcs field in the SMB_COM_NEGOTIATE Response (section 2.2.4.52.2) to 0x01, but do not enforce this limit. This allows a CIFS client to establish more virtual circuits than allowed by the MaxNumberVcs field value. Because this limit is not enforced on Windows, CIFS clients can ignore this limit and attempt to establish more than the number of virtual circuits allowed by this value. The Windows behavior of the CIFS server allows a client to exceed this limit, but other server implementations can enforce this limit and not allow this to occur.

<94> Section 2.2.4.53.1: Windows NT Server ignores the client's SessionKey.

<95> Section 2.2.4.53.1: The Windows 98 client sends only CAP_RAW_MODE and CAP_UNICODE. Windows NT clients send only CAP_NT_STATUS, CAP_UNICODE, CAP_LEVEL_II_OPLOCKS, and CAP_NT_SMBS (the latter implies CAP_NT_FIND). Windows NT Server checks only for the following capabilities in the client's SMB_COM_SESSION_SETUP_ANDX request: CAP_UNICODE, CAP_LARGE_FILES, CAP_NT_SMBS, CAP_NT_FIND, CAP_NT_STATUS, and CAP_LEVEL_II_OPLOCK.

For some capabilities, it is not necessary for the client to indicate support for a server capability in order to use that capability. For example, Windows 98 clients do not indicate support for DFS, but still request DFS referrals from the server if the server has indicated support.

<96> Section 2.2.4.53.1: Windows NT and Windows 98 clients do not set the CAP_LARGE_FILES bit.

<97> Section 2.2.4.53.1: Windows client systems that negotiate CAP_NT_SMBS also negotiate CAP_UNICODE. Windows NT servers expect that CAP_NT_SMBS and CAP_UNICODE will be negotiated together. This relationship, however, is not enforced by the server. If the client negotiates one of these capabilities but not the other, the contents of SMB_STRING fields in Windows NT server response messages are undefined and can be malformed.

<98> Section 2.2.4.53.1: Windows 98 and Windows NT clients do not set the CAP_NT_FIND capability bit. Windows NT Server, however, treats CAP_NT_FIND as set if CAP_NT_SMBS is set.

<99> Section 2.2.4.53.1: Windows NT Server does not support plaintext Unicode authentication.

<100> Section 2.2.4.53.1: Windows CIFS clients set this field based on the version and service pack level of the Windows operating system. A list of possible values for this field includes the following:

Windows OS version

NativeOS string

Windows NT 4.0 operating system

Windows NT 1381

Windows NT 3.51 operating system

Windows NT 1057

Windows 98 Second Edition

Windows 4.0

<101> Section 2.2.4.53.1: Windows CIFS clients set this field based on the version of the Windows operating system. A list of possible values for this field includes the following:

Windows OS version

NativeLanMan string

Windows NT 4.0

Windows NT 4.0

Windows NT 3.51

Windows NT 3.51

Windows 98 Second Edition

Windows 4.0

Windows NT clients add an extra string terminator following the NativeOS field, so the NativeLanMan string appears to be the empty string. If ByteCount indicates that there are more bytes in the SMB_Data.Data block, the additional bytes are the NativeLanMan string. The NativeLanMan string also contains an extra terminating null character.

<102> Section 2.2.4.53.2: Windows-based CIFS servers set this field based on the version and service pack level of the Windows operating system. The following table includes a list of possible values for this field:

Windows OS version

NativeOS string

Windows NT 3.51

Windows NT 1057

Windows NT 4.0

Windows NT 1381

Windows 98 Second Edition

Windows 4.0

Windows clients ignore the NativeOS field in the server response.

<103> Section 2.2.4.53.2: Windows-based CIFS servers set this field based on the version of the Windows operating system. The following table lists possible values for this field:

Windows OS version

NativeLanMan string

Windows NT 3.51

NT LAN Manager 3.51

Windows NT 4.0

NT LAN Manager 4.0

Windows 98 Second Edition

Windows 4.0

Windows clients ignore the NativeLanMan field in the server response.

<104> Section 2.2.4.53.2: Windows clients ignore the PrimaryDomain field in the server response.

<105> Section 2.2.4.53.2: Windows-based servers terminate the PrimaryDomain string with a single null byte if the Pad field in the response is not empty.

<106> Section 2.2.4.55.1: Windows 98 clients set this bit. Windows NT servers ignore the setting.

<107> Section 2.2.4.55.2: Windows clients ignore the NativeFileSystem field in the server response.

<108> Section 2.2.4.56: This command is neither reserved nor implemented in Windows. Windows NT servers return STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd).

<109> Section 2.2.4.58.1: Windows NT systems define this UCHAR field as follows:

bit 7 (mask 0x80): Reserved for client use.

bits 5,6 (mask 0x60): Reserved for system use.

bits 0-4 (mask 0x1F): Reserved for server use.

The above definition agrees with [SMB-CORE] as well as [CIFS], and is used in Windows NT server. [XOPEN-SMB], however, declares this field as reserved for client use. The safest course for implementers is to avoid modifying the contents of this field, whether set by the client or the server.

<110> Section 2.2.4.58.1: Windows NT server makes use of the ServerState field as follows:

 ServerState
   {
   UCHAR FileName[8];
   UCHAR FileExt[3];
   UCHAR SearchID;
   ULONG FileIndex;
   }

FileName (8 bytes): This is the name portion of the 8.3 format file name. The name is left-justified and space-padded.

FileExt (3 bytes): This is the file extension of the 8.3 format file name. It is left-justified and space-padded.

This 11-byte representation of the 8.3 format name is known as the "packed" format.

SearchID (1 byte) : This is a one-byte search identifier used by the server to uniquely identify the search operation. The use of a one-byte field implies that the NT server can manage a maximum of 256 concurrent searches per SMB session.

FileIndex (4 bytes): A server-specific index used to continue the search at the correct place in the remote directory.

<111> Section 2.2.4.61.1: Windows clients set MaxCount to nonzero values. Windows-based servers fail the request with STATUS_INVALID_SMB if MaxCount is 0x0000.

<112> Section 2.2.4.61.2: Windows NT servers set this field to 0x0000 and do not send the BufferFormat and DataLength fields.

<113> Section 2.2.4.62.1: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<114> Section 2.2.4.62.1: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This action restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<115> Section 2.2.4.62.2: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<116> Section 2.2.4.62.2: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This action restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<117> Section 2.2.4.63.1: Windows always sets ParameterOffset to an offset location, relative to the start of the SMB Header (section 2.2.3.1), where the Trans_Parameters field is expected to be. This behavior follows even if ParameterCount is zero.

<118> Section 2.2.4.63.1: Windows always sets DataCount to a value of ParameterOffset + ParameterCount. This action restricts the Trans_Data field to follow after the Trans_Parameters field, although this is not strictly a protocol requirement.

<119> Section 2.2.4.64.1: Windows NT CIFS servers allow only the FILE_OPEN option on a named pipe. All other options are ignored and considered the same as FILE_OPEN. Windows NT CIFS servers do not allow clients to "open" or to "create" a mailslot.

<120> Section 2.2.4.65: Upon receipt of this command, the Windows NT server attempts to complete outstanding commands such as those that are waiting for a thread context or waiting to access a busy resource. If the outstanding command cannot be completed successfully, the server returns an implementation-specific error.

<121> Section 2.2.4.66: Windows NT client and server both support the SMB_COM_NT_RENAME command. However, the design and implementation of this command was never completed. The SMB_COM_NT_RENAME command is not documented in [CIFS]; the only prior documentation covering this command is [SNIA].

The request structure for this command includes a Reserved field that was originally intended to access a proposed server feature that was never implemented. The SMB_DATA portion of the message also includes Buffer Format fields, making this the only non-Core Protocol command to make use of Buffer Format fields.

This command is superseded by newer commands in updated versions of the protocol (see [MS-SMB]).

<122> Section 2.2.4.66: The Windows-based server implementation of SMB_COM_NT_RENAME does not support moving a file within its existing path hierarchy. If such a move is requested, the server will copy the file instead.

<123> Section 2.2.4.66.1: Windows clients never send an SMB_COM_NT_RENAME Request (section 2.2.4.66.1) using this information level. Instead, they use SMB_COM_RENAME (section 2.2.4.8) to perform rename operations. Windows-based servers process SMB_COM_NT_RENAME Requests with this information level in the same way as an SMB_COM_RENAME Request (section 2.2.4.8.1), with the exception that they do not allow wildcards in the request.

<124> Section 2.2.4.66.1: Windows clients do not send SMB_COM_NT_RENAME Requests with the SMB_NT_RENAME_MOVE_FILE information level. Windows NT servers do not fully implement this information level, and perform a file copy instead of a rename or move if SMB_NT_RENAME_MOVE_FILE is specified.

<125> Section 2.2.4.66.1: This field was previously designated ClusterCount (as listed in [SNIA] section 2.4.13). ClusterCount is not implemented in Windows.

<126> Section 2.2.4.67.1: Windows NT4.SP6 server ignores the Identifier.

<127> Section 2.2.4.70: Support for this command was not implemented in Windows NT Server. Windows 98 and Windows NT clients do not call this command.

<128> Section 2.2.4.71: Windows NT Server returns STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd) instead of STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc) if the WordCount field in the request is set to 12; otherwise, Windows NT Server returns STATUS_ INVALID_SMB (ERRSRV/ERRerror).

<129> Section 2.2.4.72: Windows NT Server returns STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd) instead of STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc) if the WordCount field in the request is set to 12; otherwise, Windows NT Server returns STATUS_INVALID_SMB (ERRSRV/ERRerror).

<130> Section 2.2.4.73: Windows NT servers return STATUS_SMB_BAD_COMMAND (ERRSRV/ERRbadcmd) instead of STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc).

<131> Section 2.2.5.1: The TRANS_SET_NMPIPE_STATE subcommand was introduced to provide support for the SetNamedPipeHandleState() system call in OS/2 and Win32. For more information, see [MSDN-SetNmdPipeHndState]. Windows NT servers use the FilePipeInformation Information Class to implement this named pipe transaction subcommand. For more information, see [MS-FSCC] section 2.4.36.

<132> Section 2.2.5.2: Windows NT Server does not support this transaction subcommand. It returns a status of STATUS_INVALID_PARAMETER (ERRDOS/ERRinvalidparam).

<133> Section 2.2.5.3: The TRANS_QUERY_NMPIPE_STATE subcommand was introduced to provide support for the GetNamedPipeHandleState() system call in OS/2 and Win32. For more information, see [MSDN-GetNmdPipeHndState]. Windows NT servers use the FilePipeInformation Information Class to implement this named pipe transaction subcommand. For more information, see [MS-FSCC] section 2.4.36.

<134> Section 2.2.5.4: The TRANS_QUERY_NMPIPE_INFO subcommand was introduced to provide support for the GetNamedPipeInfo() system call in OS/2 and Win32. For more information, see [MSDN-GetNmdPipeInfo].Windows NT servers use the FilePipeLocalInformation Information Class to implement this named pipe transaction subcommand. For more information, see [MS-FSCC] section 2.4.37.

<135> Section 2.2.5.5: The TRANS_PEEK_NMPIPE subcommand was introduced to provide support for the PeekNamedPipe() system call in OS/2 and Win32. For more information, see [MSDN-PkNmdPipe]. Windows NT servers use FSCTL_PIPE_PEEK to implement this subcommand. For more information, see [MS-FSCC] sections 2.3.45 and 2.3.46.

<136> Section 2.2.5.5: Windows always peeks from a named pipe using the read mode that was specified when the named pipe was created. The peek operation is not affected when the TRANS_SET_NMPIPE_STATE subcommand is used to change the state of the named pipe. In addition, the operation always returns immediately and is not affected by the wait mode of the named pipe. For more information, see [MSDN-PkNmdPipe].

<137> Section 2.2.5.6: The TRANS_TRANSACT_NMPIPE subcommand was introduced to provide support for the TransactNamedPipe() system call in OS/2 and Win32. For more information, see [MSDN-TrnsactNmdPipe]. Windows NT servers use FSCTL_PIPE_TRANSCEIVE to implement this subcommand. For more information, see [MS-FSCC] sections 2.3.47 and 2.3.48.

<138> Section 2.2.5.6.2: If the Windows NT Server receives a single-request transaction where the request's DataCount field equals the TotalDataCount field and the ParameterCount field equals the TotalParameterCount field, and if the server response indicates a STATUS_BUFFER_OVERFLOW, the data read from the named pipe is included in the response's ReadData field, even if the amount of data read from the pipe exceeds the MaxDataCount field of the client's request. In this case, the response's TotalDataCount field is greater than the DataCount field and indicates the number of remaining bytes that were not transferred to the client in the response.

<139> Section 2.2.5.7: Windows NT Server permits only a 2-byte write that contains two null padding bytes, and requires that the pipe is in message mode. If these conditions are not met, NT server returns a STATUS_INVALID_PARAMETER error.

<140> Section 2.2.5.10: The TRANS_WAIT_NMPIPE subcommand was introduced to provide support for the WaitNamedPipe() system call in OS/2 and Win32. For more information, see [MSDN-WaitNmdPipe]. Windows NT servers use FSCTL_PIPE_WAIT to implement this subcommand. For more information, see [MS-FSCC] sections 2.3.49 and 2.3.50.

<141> Section 2.2.5.10.1: Windows NT server honors the Timeout field for this transaction.

<142> Section 2.2.5.10.1: Windows NT servers ignore the Priority value in the TRANS_WAIT_NMPIPE Request (section 2.2.5.10.1), and do not provide a default priority.

<143> Section 2.2.5.11: The TRANS_CALL_NMPIPE subcommand was introduced to provide support for the CallNamedPipe() system call in OS/2 and Win32. For more information, see [MSDN-CallNmdPipe]. Windows NT servers use FSCTL_PIPE_TRANSCEIVE to implement this subcommand. For more information, see [MS-FSCC] sections 2.3.47 and 2.3.48.

<144> Section 2.2.5.11.2: Windows 98 clients misread the number of data bytes returned. For more information, see [MSKB-235717].

<145> Section 2.2.5.11.2: When the TRANS_CALL_NMPIPE (section 2.2.5.11) operation returns STATUS_BUFFER_OVERFLOW, Windows-based servers set the SetupCount field value in the TRANS_CALL_NMPIPE Response (section 2.2.5.11.2) to the SetupCount field value in the TRANS_CALL_NMPIPE Request (section 2.2.5.11.1) * 2.

<146> Section 2.2.6.3.1: If the client sends an empty string (0x00 or 0x0000) in the FileName field for the TRANS2_FIND_NEXT2 Request (section 2.2.6.3.1), Windows NT servers return no data in the Trans2_Data block. The SearchCount field value in the Trans2_Parameters block is set to zero (0x0000).

<147> Section 2.2.6.8.2: If the information level is SMB_QUERY_FILE_ALL_INFO, Windows NT servers append 4 additional bytes at the end of the Trans2_Data block that are set to arbitrary values and that are ignored on receipt.

<148> Section 2.2.7.1.1: Windows NT Server requires that this field be aligned to a 32-bit boundary. No padding is required, however, because the NT_Trans_Data block is aligned, and the SecurityDescriptor field is always a multiple of 32 bits.

<149> Section 2.2.7.2: Windows clients generate IOCTL and FSCTL codes that are supported only by Windows NT Server.

<150> Section 2.2.7.3: Security descriptors are typically useful only to Windows clients.

<151> Section 2.2.7.4.2: The Windows NT Server implementation of NT_TRANSACT_NOTIFY_CHANGE always returns the names of changed files in Unicode format.

<152> Section 2.2.7.6: Security descriptors are typically useful only to Windows clients.

<153> Section 2.2.8.1.1: Windows NT servers append a single NULL padding character to this field. If CAP_UNICODE has been negotiated, the server appends two NULL bytes to this field; otherwise, one NULL byte is appended. The length of the terminating NULL character is not included in the value of the FileNameLength field.

<154> Section 2.2.8.1.2: Windows NT servers always append a single NULL padding byte to the FileName field. The length of this additional byte is not included in the value of the FileNameLength field.

<155> Section 2.2.8.1.3: If CAP_UNICODE has been negotiated, Windows NT servers set the FileNameLength field to an arbitrary value.

<156> Section 2.2.8.1.3: Windows NT servers always append a single NULL padding byte to the FileName field.  The length of this additional byte is not included in the value of the FileNameLength field.

<157> Section 2.2.8.1.4: Windows-based CIFS servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.

<158> Section 2.2.8.1.4: If CAP_UNICODE has not been negotiated, Windows NT servers include the length of the terminating NULL byte in the value of the FileNameLength field.

<159> Section 2.2.8.1.4: Windows NT servers append an arbitrary number of extra NULL padding bytes to the FileName field. The length of these additional NULL bytes is not included in the value of the FileNameLength field unless CAP_UNICODE has not been negotiated. If CAP_UNICODE has not been negotiated, only the length of the first NULL byte is included in the value of the FileNameLength field.

<160> Section 2.2.8.1.5: Windows-based CIFS servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.

<161> Section 2.2.8.1.5: If CAP_UNICODE has not been negotiated, Windows NT servers include the length of one NULL padding byte in the FileNameLength field value.

<162> Section 2.2.8.1.5: Windows NT servers append an arbitrary number of extra NULL padding bytes to the FileName field. The length of these additional NULL bytes is not included in the value of the FileNameLength field unless CAP_UNICODE has not been negotiated.  If CAP_UNICODE has not been negotiated, only the length of the first NULL byte is included in the value of the FileNameLength field.

<163> Section 2.2.8.1.6: Windows-based CIFS servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.

<164> Section 2.2.8.1.6: If CAP_UNICODE has not been negotiated, Windows NT servers include the length of one NULL padding byte in the FileNameLength field value.

<165> Section 2.2.8.1.6: Windows NT servers append an arbitrary number of extra NULL padding bytes to the FileName field. The length of these additional NULL bytes is not included in the value of the FileNameLength field unless CAP_UNICODE has not been negotiated.  If CAP_UNICODE has not been negotiated, only the length of the first NULL byte is included in the value of the FileNameLength field.

<166> Section 2.2.8.1.7: Windows-based CIFS servers set the FileIndex field to a nonzero value if the underlying object store supports indicating the position of a file within the parent directory.

<167> Section 2.2.8.1.7: If CAP_UNICODE has not been negotiated, Windows NT servers include the length of one NULL padding byte in the FileNameLength field value.

<168> Section 2.2.8.1.7: Windows NT servers append an arbitrary number of extra NULL padding bytes to the FileName field. The length of these additional NULL bytes is not included in the value of the FileNameLength field unless CAP_UNICODE has not been negotiated.  If CAP_UNICODE has not been negotiated, only the length of the first NULL byte is included in the value of the FileNameLength field.

<169> Section 2.2.8.2.1: Windows-based servers always return zero (0x00000000).

<170> Section 2.2.8.2.2: Windows NT servers use the FileFsVolumeInformation information class to retrieve file system volume information. See [MS-FSCC], section 2.5.9.

If the VolumeLabelLength field of the FILE_FS_VOLUME_INFORMATION data element contains a value greater than 13, an error response is returned to the client with a status of STATUS_BUFFER_OVERFLOW (ERRDOS/ERRmoredata). Otherwise, the ulVolSerialNbr field is copied from the VolumeSerialNumber field of the FILE_FS_VOLUME_INFORMATION data element. VolumeLabelLength is copied to cCharCount and VolumeLabel is copied to VolumeLabel.

Windows clients request SMB_INFO_VOLUME only if CAP_NT_SMBS has not been negotiated. If CAP_NT_SMBS has been negotiated, Windows clients request SMB_QUERY_FS_VOLUME_INFO instead of SMB_INFO_VOLUME.

If CAP_UNICODE has been negotiated, the contents of the VolumeLabel field returned by Windows NT servers is undefined.

If CAP_UNICODE has not been negotiated, Windows NT servers append an arbitrary number of extra NULL padded bytes to the VolumeLabel field.

<171> Section 2.2.8.2.3: Windows NT Server servers use the FileFsVolumeInformation ([MS-FSCC] section 2.5.9) information class to retrieve file system volume information.

<172> Section 2.2.8.2.4: Windows NT servers use the FileFsSizeInformation ([MS-FSCC] section 2.5.8) information class to retrieve file system allocation and size information.

<173> Section 2.2.8.2.5: Windows NT servers use the FileFsDeviceInformation ([MS-FSCC] section 2.5.10) information class to retrieve file system device information.

<174> Section 2.2.8.2.6: Windows NT Server use the FileFsAttributeInformation ([MS-FSCC] section 2.5.1) informationclass to retrieve file system attribute information.

 SMB_QUERY_FS_ATTRIBUTE_INFO
   {
   ULONG FileSystemAttributes;
   LONG  MaxFileNameLengthInBytes;
   ULONG LengthOfFileSystemName;
   WCHAR FileSystemName[LengthOfFileSystemName/2];
   }
 

<175> Section 2.2.8.3.6: Windows NT Server use the FileBasicInformation ([MS-FSCC] section 2.4.7) information class to retrieve timestamp and extended file attribute information for a file.

<176> Section 2.2.8.3.7: Windows NT servers use the FileStandardInformation ([MS-FSCC] section 2.4.45) information class to retrieve the specified standard information for a file.

<177> Section 2.2.8.3.8: Windows NT Server use the FileEaInformation ([MS-FSCC] section 2.4.12) information class to EA  size information for a file.

<178> Section 2.2.8.3.9: Windows NT Server use the FileNameInformation ([MS-FSCC]  section 2.4.31) information class to retrieve the long name for a file.

<179> Section 2.2.8.3.11: Windows NT servers use the FileAlternateNameInformation ([MS-FSCC] section 2.4.5) information class to retrieve the 8.3 format name for a file.

<180> Section 2.2.8.3.12: Windows NT Server use the FileStreamInformation ([MS-FSCC] section 2.4.47) information class to retrieve the stream information for a file.

<181> Section 2.2.8.3.13: Windows NT Server use the FileCompressionInformation ([MS-FSCC] section 2.4.9) information class to retrieve the compression information for a file.

<182> Section 2.2.8.4.3: Windows NT servers use the FileBasicInformation ([MS-FSCC] section 2.4.7) information class to set timestamp and extended file attribute information for a file.

<183> Section 2.2.8.4.4: Windows NT servers use the FileDispositionInformation ([MS-FSCC] section 2.4.11) information class to mark or unmark a file for deletion.)

<184> Section 2.2.8.4.5: Windows NT servers use the FileAllocationInformation ([MS-FSCC] section 2.4.4) information class to set allocation size information for a file.

<185> Section 2.2.8.4.6: Windows NT servers use the FileEndOfFileInformation ([MS-FSCC] section 2.4.13) information class to set end-of-file information for a file.

<186> Section 3.1.5.2: Windows clients do not provide a configuration parameter to specify LMv2 authentication. Rather, a single system parameter enables both LMv2 and NTLMv2 authentication. For more information, see [MSFT-SecurityWatch].

<187> Section 3.2.1.1: Windows NT Workstation 4.0 added support for the ability to enable and require signing in Service Pack 3 (SP3). See [ENSIGN].

<188> Section 3.2.1.5: Windows 98 and NT 4 Workstation clients do not request Exclusive or Level II OpLocks.

<189> Section 3.2.2.1: Windows NT and Windows 98 CIFS clients implement this timer with a default value of 30 seconds.

<190> Section 3.2.3: Windows 98 clients set Client.PlaintextAuthenticationPolicy to Disabled by default. Plain text authentication can be enabled by selecting the HKLM\System\CurrentControlSet\Services\VxD\VNETSUP registry path and setting the EnablePlainTextPassword registry value to 1.

Windows NT clients prior to NT 4 SP3 set Client.PlaintextAuthenticationPolicy to Enabled by default. Windows NT 4.0 SP3 and above client systems set Client.PlaintextAuthenticationPolicy to Disabled by default. Plain text authentication can be enabled by selecting the HKLM\System\CurrentControlSet\Services\Rdr\Parameters registry path and setting the EnablePlainTextPassword registry value to 1.

Windows 98 clients determine Client.LMAuthenticationPolicy and Client.NTLMAuthenticationPolicy based upon the value of the LMCompatibility registry key.  See [MSFT-SecurityWatch] and [IMP-CIFS] section 15.5.7 for further information. Windows 98 clients do not support NTLMv2 authentication, but support can be added. See [MSKB-288358].

Windows NT 4.0 Workstation clients determine Client.LMAuthenticationPolicy and Client.NTLMAuthenticationPolicy based upon the value of the LMCompatibilityLevel registry key. Support for NTLMv2 authentication was added to Windows NT 4.0 in SP4. See [MSFT-SecurityWatch], [MSKB-239869], and [IMP-CIFS] section 15.5.7 for further information.

<191> Section 3.2.3: Windows NT 3.51 servers do not support signing. Windows NT 4.0 added support for the ability to enable and require signing in Service Pack 3 (SP3). See [ENSIGN].

<192> Section 3.2.3: Windows NT clients use a default value of 45 seconds. This value is obtained from a system-wide configuration parameter. See [KB102067] for more information.

<193> Section 3.2.3: The default maximum buffer size for Windows 98 and NT 4 Workstation clients is 4356 bytes.

<194> Section 3.2.3: Windows-based clients set the list of supported dialect identifier strings in the following order.

  • PC NETWORK PROGRAM 1.0

  • LANMAN1.0

  • MICROSOFT NETWORKS 3.0

  • LM1.2X002

  • LANMAN2.1

  • NT LM 0.12

This technical document describes only the NT LM 0.12 dialect behavior; see section 1.

<195> Section 3.2.3: By default, Windows 98 and NT 4 Workstation clients set the Client.Connection.MaxMpxCount value to 50. This can be configured using the MaxCmds registry setting.

<196> Section 3.2.4.1.4: Windows 98 and Windows NT 4.0 clients do not send AndX chains longer than two commands in length. Windows NT Server 4.0 produces unexpected errors if an untested AndX chain is received.

<197> Section 3.2.4.1.5: Windows 98 clients and Windows NT clients and servers do not support sending a transaction with secondary messages as part of an AndX chain. The SMB_COM_SESSION_SETUP_ANDX and SMB_COM_TREE_CONNECT_ANDX commands each permits an SMB_COM_TRANSACTION as a follow-on command. Transactions that are part of an AndX chain are "complete". That is, the entire transaction request fits within the primary transaction request.

<198> Section 3.2.4.2.1: The Windows implementation, by default, attempts to connect on all available SMB transports (NetBIOS-compatible and direct IPX) simultaneously and selects the one that succeeds the fastest. Any connection that is not selected is immediately closed. Windows also allows an upper layer to specify what transport to use.

<199> Section 3.2.4.2.4: Windows NT servers do not support share level access control.

<200> Section 3.2.4.2.4: Null sessions are also used to allow clients to access the browse list and list of available server shares. See [MS-BRWS] for more information on the Browser Service.

<201> Section 3.2.4.2.4: Windows NT Server does not support share level access control.

<202> Section 3.2.4.2.4: Windows clients determine the authentication type using the following rules:

  
 IF Client.NTLMAuthenticationPolicy NOT EQUALS Disabled THEN
        USE NT LAN Manager (NTLM) Response OR NT LAN Manager version 2 (NTLMv2) Response
 ELSE IF Client.LMAuthenticationPolicy NOT EQUALS Disabled THEN
        USE LAN Manager (LM) Response OR LAN Manager version 2 (LMv2) Response
 ELSE IF Client.PlaintextAuthenticationPolicy EQUALS Enabled THEN
       USE Plaintext Authentication
 ELSE
        Fail the Authentication
 END IF
 

<203> Section 3.2.4.2.4: Windows 98 and NT 4 Workstation clients do not retry authentication.

<204> Section 3.2.4.5: Windows 98and Windows NT Workstation 4.0 clients never request exclusive OpLocks.

<205> Section 3.2.4.14.1: If a Windows-based server does not support the READ RAW capability, but a client sends an SMB_COM_READ_RAW request to the server, the server sends a zero-length response.

<206> Section 3.2.4.15: Windows clients set the first two bytes of the SMB_Data.Bytes.Data field to the SMB_Parameters.Words.Remaining field value for the first write request.

<207> Section 3.2.4.15.1: Windows 98 and NT clients set the Timeout field to 0x00000000 in this request.

If the server has indicated support for Raw Mode by setting CAP_RAW_MODE in the SMB_COM_NEGOTIATE Response (section 2.2.4.52.2), a Windows NT client might send SMB_COM_WRITE_RAW, even if it has not indicated support for RAW WRITE, by setting the CAP_RAW_MODE bit in the Capabilities bit field of the SMB_COM_SESSION_SETUP_ANDX Request (section 2.2.4.53.1). This is expected to succeed, because the server has already indicated support for the Raw Mode.

<208> Section 3.2.4.43: Support for DFS Client capabilities was introduced in Windows NT 4.0 Workstation and Server.

<209> Section 3.2.5.1.2: Windows-based clients that use message signing disconnect the connection on receipt of an incorrectly signed message.

<210> Section 3.2.5.13: Windows NT CIFS servers maintain a 64-bit offset value internally, but return only the lower-order 32-bits.

<211> Section 3.2.6.1: Windows NT clients use a default Client.SessionTimeoutValue value of 45 seconds. Additional time will be added depending upon the size of the message. See [KB102067] for more information.

<212> Section 3.2.6.1: Windows NT and Windows 98 CIFS clients periodically scan for any commands that have not completed.  If there are outstanding commands that have exceeded the Client.SessionTimeoutValue, an  SMB_COM_ECHO (section 2.2.4.39) is sent to determine whether or not the connection has been lost. Regardless of whether the client receives an SMB_COM_ECHO Response (section 2.2.4.39.2), it closes the connection if there is no response to the outstanding commands that have exceeded the Client.SessionTimeoutValue.

<213> Section 3.3.1.1: Windows NT Server 4.0 added support for the ability to enable and require signing in Service Pack 3 (SP3). See [ENSIGN].

<214> Section 3.3.1.2: Windows NT servers allow the sharing of printers and traditional file shares.

<215> Section 3.3.1.2: In Windows, this ADM element contains the security descriptor for the share.

<216> Section 3.3.1.3: Windows NT Server 4.0 does not include the CID as a lookup key to identify the list of pending requests that are associated with the SMB transport in Server.Connection.PendingRequestTable; it includes only the UID, TID, PID, and MID.

<217> Section 3.3.2.1: The default OpLock acknowledgment time-out on Windows NT Servers is 35 seconds. This value is controlled by the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\OplockBreakWait registry parameter. See [KB129202].

<218> Section 3.3.2.2: The default idle timer time-out value for Windows NT 4.0 is 15 minutes. See [KB297684] for more information on Windows NT idle timer settings.

<219> Section 3.3.3: Windows NT Server initializes Server.ShareLevelAuthentication to FALSE because Windows NT Server does not support share-level security.

<220> Section 3.3.3: Windows-based server sets the list of supported dialect identifier strings in the following order:

  • PC NETWORK PROGRAM 1.0

  • LANMAN1.0

  • MICROSOFT NETWORKS 3.0

  • LM1.2X002

  • LANMAN2.1

  • NT LM 0.12

This technical document describes only the NT LM 0.12 dialect behavior; see section 1.

<221> Section 3.3.3: By default, Windows NT Server accepts plaintext authentication.

Windows NT Server determines Server.LMAuthenticationPolicy and Server.NTLMAuthenticationPolicy based upon the value of the LMCompatibilityLevel registry key. Support for NTLMv2 authentication was added in Windows NT 4.0 operating system Service Pack 4 (SP4). See [MSFT-SecurityWatch], [MSKB-239869], and [IMPCIFS] section 15.5.7 for further information.

<222> Section 3.3.3: The default MaxBufferSize on Windows NT Server is 4356 (0x00001104) bytes (4KB + 260 bytes) if the server has 512 MB of memory or less. If the server has more than 512 MB of memory, the default MaxBufferSize is 16644 (0x00004104) bytes (16KB + 260Bytes). Windows NT Server always uses a MaxBufferSize value that is a multiple of four (0x00000004). The MaxBufferSize can be configured through the following registry setting:

 HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizReqBuf

<223> Section 3.3.3: On Windows NT Server, the default value is 50 (0x0032). This value can be set using the MaxMpxCt registry key.

<224> Section 3.3.3: Windows NT 3.51 servers do not support signing. Windows NT 4.0 added support for the ability to enable and require signing in Windows NT 4.0 operating system Service Pack 3 (SP3). See [ENSIGN] for more information.

<225> Section 3.3.3: Windows-based servers set the Server.MaxRawSize value to 65,536 (0x00010000) bytes (64KB).

<226> Section 3.3.3: Windows-based servers initialize Server.MaxSearches to 2048.

<227> Section 3.3.4.1: When signing is neither enabled nor required:

<228> Section 3.3.4.1.1: Windows-based servers set the SMB_Header.Reserved field of the response to the SMB_Header.Reserved value received in the request.

<229> Section 3.3.4.1.2: If 32-bit status codes have not been negotiated, Windows-based servers convert NTSTATUS codes to their equivalent SMBSTATUS Class/Code pairs before sending the response.

<230> Section 3.3.4.2: Windows-based servers receive the type of OpLock that has been requested to be broken from the object store, as described in [MS-FSA] section 2.1.5.18.3, with the following output element mapping:

<231> Section 3.3.4.2: Windows NT Server 4.0 always sets the Timeout, NumberOfUnlocks, NumberofLocks, and ByteCount fields to zero, and the client ignores these fields.

<232> Section 3.3.4.3: Support for DFS Server capability was introduced in Windows NT Server 4.0 operating system with Service Pack 2 (SP2).

<233> Section 3.3.4.17: For each supported transport type as listed in section 2.1, the Windows CIFS server attempts to form an association with the specified device with local calls specific to each supported transport type and rejects the entry if none of the associations succeed.

<234> Section 3.3.4.17: On Windows, ServerName is used only when the transport is NBT (section 2.1.1.2).

<235> Section 3.3.4.17: On Windows, servers manage listening in TDI transport drivers through the interface described in [MSDN-MakeEndpoint].

<236> Section 3.3.5.1: On Windows, the transport name is obtained from the TDI device object that was opened as part of transport initialization and returned by the new connection indication. For more information on TDI device objects, see [MSDN-TDIDeviceObj]. Possible Windows-specific values for Server.Connection.TransportName are listed in a product behavior note attached to [MS-SRVS] section 2.2.4.96.

<237> Section 3.3.5.1: Windows-based servers do not generate a token and always set Server.Connection.SessionKey to zero.

<238> Section 3.3.5.2: Windows NT servers perform basic validation tests on received command requests before determining whether or not the command is Obsolete or Not Implemented. If a request is found to be incorrectly formatted, the server returns STATUS_INVALID_SMB (ERRSRV/ERRerror).

<239> Section 3.3.5.2: Windows NT Server does not validate the TID field in SMB_COM_ECHO requests.

<240> Section 3.3.5.2.5: Windows NT servers fail a transaction request with STATUS_INSUFF_SERVER_RESOURCES, if (SetupCount + MaxSetupCount + TotalParameterCount + MaxParameterCount + TotalDataCount + MaxDataCount) is greater than 65*1024.

<241> Section 3.3.5.3: Windows-based servers create directories within the object store as described in [MS-FSA] sections 2.1.5.1 and 2.1.5.1.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID field to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

  • PathName is the SMB_Data.Bytes.DirectoryName field from the request.

  • SecurityContext is found by using the SMB_Header.UID field to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set to FILE_TRAVERSE, which has the same value as FILE_EXECUTE: 0x00000020.

  • ShareAccess is set to 0x00000000.

  • CreateOptions is set to FILE_DIRECTORY_FILE.

  • CreateDisposition is set to FILE_CREATE.

  • DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the Open returned from the process described in [MS-FSA] section 2.1.5.1 is closed. All other results are ignored.

<242> Section 3.3.5.4: Windows-based servers delete directories within the object store by opening them as described in [MS-FSA] section 2.1.5.1, with DesiredAccess set to DELETE. The following is a mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching treeConnect in the Server.Connection.TreeConnectTable, which in turn provides the Server.TreeConnect.Share. Server.TreeConnect.Share points to an entry in the Server.Share table. The Server.Share.LocalPath is the path to the root of the share. An Open directory handle representing Server.Share.LocalPath is passed as RootOpen.

  • PathName is the SMB_Data.Bytes.DirectoryName field from the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set to DELETE (0x00010000).

  • ShareAccess is set to 0x00000000.

  • CreateOptions is set to FILE_DIRECTORY_FILE.

  • CreateDisposition is set to FILE_OPEN.

  • DesiredFileAttributes is set to 0x00000000.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The file is opened as described in [MS-FSA] section 2.1.5.1, and the returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response and processing is complete.

If the operation is successful, the file is marked to be deleted when closed as described in [MS-FSA] section 2.1.5.15, passing the following mapping of input elements:

  • Open is the Open returned in the previous operation.

  • FileInformationClass is FileDispositionInformation. See [MS-FSA] section 2.1.5.15.3.

  • InputBuffer is the FILE_DISPOSITION_INFORMATION data element specified in [MS-FSCC] section 2.4.11. InputBuffer.DeletePending is set to TRUE.

  • InputBufferLength is the size of the FILE_DISPOSITION_INFORMATION data element.

If the Set File Information operation fails, the Status is returned in an Error Response and processing is complete. If the operation is successful, the Open is immediately closed, which results in the deletion of the file. All other results are ignored.

<243> Section 3.3.5.4: Windows NT servers close any SearchOpen with a matching TID where the canonicalized directory name derived from the SMB_Data.Bytes.DirectoryName field is a prefix of the canonicalized full search path, including the filename portion. This could potentially result in unrelated SearchOpens being closed.

<244> Section 3.3.5.5: Windows NT Server always ignores the SearchAttributes field on Open and Create operations, and searches for files by name only.

<245> Section 3.3.5.5: Windows-based servers open files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

  • PathName is the SMB_Data.Bytes.FileName field from the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set as follows:

    • The AccessMode subfield of the AccessMode field in the request is used to set the value of DesiredAccess. The AccessMode subfield represents the lowest order four bits of the AccessMode field (0x0007), as shown in the table in section 2.2.4.3.1. The mapping of values is as follows.

    AccessMode.AccessMode

    DesiredAccess

    0

    GENERIC_READ 0x80000000

    1

    GENERIC_WRITE | FILE_READ_ATTRIBUTES0x40000000 | 0x00000080

    2

    GENERIC_READ | GENERIC_WRITE0x80000000 | 0x40000000

    3

    GENERIC_READ | GENERIC_EXECUTE0x80000000 | 0x20000000

    • For any other value of AccessMode.AccessMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).

  • ShareAccess is set as follows:

    • The SharingMode subfield of the AccessMode field in the request is used to set the value of ShareAccess. The SharingMode subfield is a 4-bit subfield of the AccessMode field (0x0070), as shown in the table in section 2.2.4.3.1. The mapping of values is as follows.

    AccessMode.SharingMode

    ShareAccess

    0

    Compatibility mode (see below)

    1

    0x0L (don't share, exclusive use)

    2

    FILE_SHARE_READ

    3

    FILE_SHARE_WRITE

    4

    FILE_SHARE_READ | FILE_SHARE_WRITE

    • For Compatibility mode, special filename suffixes (after the '.' in the filename) are mapped to SharingMode 4. The special filename suffix set is: "EXE", "DLL", "SYM, "COM". All other file names are mapped to SharingMode 3.

    • If AccessMode field in the request is 0xFF, and the file is already open on the server, the current sharing mode of the existing Open is preserved and a FID for the file is returned. If the file is not already open on the server, the server attempts to open the file using SharingMode 1.

    • For any other value of AccessMode.SharingMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).

  • CreateOptions is set to (FILE_NON_DIRECTORY_FILE | FILE_COMPLETE_IF_OPLOCKED). If the SMB_Header.Flags2 SMB_FLAGS2_KNOWS_EAS flag is not set, then the FILE_NO_EA_KNOWLEDGE bit is also set. The FILE_WRITE_THROUGH bit is set based on the SMB_Parameters. Words.AccessMode.WritethroughMode bit.

  • CreateDisposition is set to FILE_OPEN.

  • DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

  • The returned Status is copied into the SMB_Header.Status field of the response.  If the operation fails, the Status is returned in an Error Response and processing is complete.

  • If the operation is successful, processing continues as follows:

  • If the SMB_FLAGS_OPLOCK flag is set in the SMB_Header.Flags of the request, then an OpLock is being requested. Windows-based servers obtain OpLocks as described in [MS-FSA] section 2.1.5.18, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operation.

    • Type is LEVEL_BATCH if the SMB_FLAGS_OPBATCH flag is set in the SMB_Header.Flags of the request; otherwise, it is LEVEL_ONE.

  • If an OpLock is granted, the SMB_Header.Flags SMB_FLAGS_OPLOCK and SMB_FLAGS_OPBATCH flags are copied from the request to the response. Otherwise, both flags are set to zero in the response.

  • The SMB_Parameters.Words.AccessMode from the request is copied to the response.

  • Windows-based servers obtain the SMB_Parameters.Words.FileAttributes and SMB_Parameters.Words.LastModified response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileBasicInformation.

  • If the query fails, the Status is returned in an Error Response and processing is complete. Otherwise:

    • SMB_Parameters.Words.FileAttributes is set to OutputBuffer.FileAttributes.

    • SMB_Parameters.Words.LastModified is set to OutputBuffer.ChangeTime.

  • Windows-based servers obtain the SMB_Parameters.Words.FileSize response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileStandardInformation.

  • If the query fails, the Status is returned in an Error Response and processing is complete.  Otherwise:

    • SMB_Parameters.Words.FileSize is set to the lowest-order 32 bits of OutputBuffer.EndOfFile.

  • If the query fails, the Status is returned in an Error Response and processing is complete.

  • A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.

While opening an existing file, the underlying object store checks for the necessity of an Oplock break, as described in [MS-FSA] section 2.1.4.12, and if necessary, notifies the server, as described in section 3.3.4.2 and defers the opening of the file until the server acknowledges the Oplock break, as described in section 3.3.5.30.

<246> Section 3.3.5.6: Windows-based servers ignore the CreationTime field in the SMB_COM_CREATE Request (section 2.2.4.4.1).

<247> Section 3.3.5.6: When opening, overwriting, deleting, or renaming a file, Windows NT Server checks for sharing violations. If a sharing violation would be generated by the operation, by default the server delays for 200 ms and then tests again for a sharing violation. By default the server retries five times, for a total delay of approximately one second, before giving up and returning the sharing violation error. The sharing violation delay time and number of retries are configurable as described in [MSKB-150384].

<248> Section 3.3.5.6: Windows-based servers create files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching TreeConnect in the Server.Connection.TreeConnectTable, which in turn provides the Server.TreeConnect.Share. Server.TreeConnect.Share points to an entry in the Server.Share table. The Server.Share.LocalPath is the path to the root of the share. An Open directory handle representing Server.Share.LocalPath is passed as RootOpen.

  • PathName is the SMB_Data.Bytes.FileName field from the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set to (GENERIC_READ | GENERIC_WRITE).

  • ShareAccess is set to FILE_SHARE_WRITE. If the file extension (after the "." in the filename) is in the special filename suffix set ("EXE", "DLL", "SYM", "COM"), ShareAccess is set to FILE_SHARE_WRITE | FILE_SHARE_READ).

  • DesiredFileAttributes is set as follows:

    • DesiredFileAttributes is set to the bitwise AND of the FileAttributes field in the request  and

      (SMB_FILE_ATTRIBUTE_READONLY |

      SMB_FILE_ATTRIBUTE_HIDDEN   |

      SMB_FILE_ATTRIBUTE_SYSTEM   |

      SMB_FILE_ATTRIBUTE_ARCHIVE  |

      SMB_FILE_ATTRIBUTE_DIRECTORY ).

    • If the resulting value of DesiredFileAttributes is zero, DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL.

  • CreateDisposition is set to FILE_OVERWRITE_IF.

    • If the SMB_Header.Flags2 SMB_FLAGS2_KNOWS_EAS flag is not set, the FILE_NO_EA_KNOWLEDGE bit is also set.

  • CreateOptions is set to FILE_NON_DIRECTORY_FILE.

    • If the WritethroughMode bit of the SMB_Parameters.Words.AccessMode field is set, the FILE_WRITE_THROUGH bit is also set.

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response and processing is complete.

If the operation is successful, processing continues as follows:

  • If the SMB_FLAGS_OPLOCK flag is set in the SMB_Header.Flags of the request, an OpLock is being requested. Windows-based servers obtain OpLocks as described in [MS-FSA] section 2.1.5.18, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operation.

    • Type is LEVEL_BATCH if the SMB_FLAGS_OPBATCH flag is set in the SMB_Header.Flags of the request; otherwise, it is LEVEL_ONE.

      If an OpLock is granted, the SMB_Header.Flags SMB_FLAGS_OPLOCK and SMB_FLAGS_OPBATCH flags are copied from the request to the response. Otherwise, both flags are set to zero in the response.

  • Windows-based servers set the LastWriteTime of the file if the SMB_Parameters.Words.CreationTime in the request is not zero or -1 (0xFFFFFFFF). Windows-based servers set this value as described in [MS-FSA] section 2.1.5.15, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileBasicInformation.

      • InputBuffer.CreationTime, InputBuffer.LastAccessTime, InputBuffer.ChangeTime, and InputBuffer.FileAttributes are each set to zero.

      • InputBuffer.LastWriteTime is set to the time value in SMB_Parameters.Words.CreationTime.

        The result of the set operation is ignored.

  • A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.

<249> Section 3.3.5.7: Windows-based servers update the last modification time for the file, as described in [MS-FSA] section 2.1.5.15.2, with the following mapping of input elements:

  • Open is the Open corresponding to the input FID.

  • InputBuffer.LastWriteTime is set to SMB_Parameters.Word.LastTimeModified.

  • FileInformationClass is FileBasicInformation ([MS-FSCC] section 2.4.7).

  • InputBuffer.CreationTime, InputBuffer.LastAccessTime, InputBuffer.ChangeTime and InputBuffer.FileAttributes are all set to zero.

<250> Section 3.3.5.7: Windows-based servers close an existing Open in the object store as described in [MS-FSA] section 2.1.5.5, Server Requests Closing an Open. The returned status is copied into the SMB_Header.Status field of the response. Any Oplocks held by the Open are cleaned up as described in Phase 8 -- Oplock Cleanup in [MS-FSA] section 2.1.5.5.

<251> Section 3.3.5.7: Windows-based servers release a byte-range lock from the underlying object store as described in [MS-FSA] section 2.1.5.9, with the following mapping of input elements for each element X in the Server.Open.Locks array:

  • Open is the Open indicated by the FID.

  • FileOffset is the Server.Open.Locks[X].ByteOffset if the entry is formatted as a LOCKING_ANDX_RANGE32 structure, or Server.Open.Locks[X].ByteOffsetHigh and Unlocks[X].ByteOffsetLow if the entry is formatted as a LOCKING_ANDX_RANGE64 structure.

  • LOCKING_ANDX_RANGE32 structure, or Server.Open.Locks[X].LengthInBytesHigh and Server.Open.Locks[X].LengthInBytesLow if the entry is formatted as a LOCKING_ANDX_RANGE64 structure

<252> Section 3.3.5.8: Windows-based servers flush a file by passing the Open to the algorithm described in [MS-FSA] section 2.1.5.7. The returned Status is copied into the SMB_Header.Status field of the response.

<253> Section 3.3.5.9: Windows processes any required Oplock break notification to SMB prior to deletion via the interface described in [MS-FSA] section 2.1.5.18.3 and defers the delete operation until acknowledged via the interface in [MS-FSA] section 2.1.5.19.

<254> Section 3.3.5.9: The [XOPEN-SMB] specification (section 7.12) indicates that the server deletes all files matching the search criteria that it can delete and returns Success if any is deleted, stating "If a wildcard pathname matches more than one file, and not all of the files could be unlinked, the request fails silently". Windows NT CIFS servers search for and delete files matching the search criteria in a sequential fashion. If an error occurs, processing stops, and the error is returned in the Status field of an error response message. No more matching files are deleted.

<255> Section 3.3.5.9: When opening, overwriting, deleting, or renaming a file, Windows NT Server checks for sharing violations. If a sharing violation would be generated by the operation, the server delays for 200 ms and then tests again for a sharing violation. The server retries five times, for a total delay of approximately one second, before giving up and returning the sharing violation error.

<256> Section 3.3.5.9: Windows-based servers implement wildcard file deletion as a three-step process.

Step 1: Wildcard Matching

Windows-based servers match wildcard patterns within directories as described in [MS-FSA] section 2.1.5.6. The following is a mapping of input elements:

  • Open is an Open resulting from opening the directory portion of the SMB_Data.Bytes.FileName field from the request.

  • FileNamePattern is the final component of the FileName field.

If the operation fails, the Status is returned in an Error Response and processing is complete.  Otherwise, all files that match the FileNamePattern are candidates for deletion. The next step is performed for each file that matches the wildcard pattern.

Step 2:  SearchAttribute Filtering

Windows-based servers match SearchAttributes as follows:

If both SMB_FILE_ATTRIBUTE_HIDDEN and SMB_FILE_ATTRIBUTE_SYSTEM are specified in SearchAttributes, all files match.

If either or both of the SMB_FILE_ATTRIBUTE_HIDDEN or SMB_FILE_ATTRIBUTE_SYSTEM are not set, the server queries the object store for the attributes of the file.

  • Windows-based servers obtain FileAttributes values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open resulting from opening the file to be queried.

    • FileInformationClass is FileBasicInformation.

      If the query fails, the file does not match and is not deleted. Otherwise:

    • All bits except the SMB_FILE_ATTRIBUTE_HIDDEN and SMB_FILE_ATTRIBUTE_SYSTEM bits are cleared from the FileAttributes returned from the query operation.

      FileAttributes &= (FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_HIDDEN)

    • If the Value of FileAttributes, cast to a USHORT, does not exactly match SearchAttributes, the file does not match and is not deleted. Otherwise, the Open is closed and the matching FileName is passed to the next step.

Step 3: File Deletion

If there are no matching FileNames to be deleted, the server returns an Error Response with Status set to STATUS_NO_SUCH_FILE (ERRDOS/ERRbadfile) and processing is complete.  Otherwise:

Windows-based servers delete files and directories within the object store by opening them as described in [MS-FSA] section 2.1.5.1 with DesiredAccess set to DELETE. The following is a mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching TreeConnect in the Server.Connection.TreeConnectTable, which in turn provides the Server.TreeConnect.Share. Server.TreeConnect.Share points to an entry in the Server.Share table. The Server.Share.LocalPath is the path to the root of the share. An Open directory handle representing Server.Share.LocalPath is passed as RootOpen.

  • PathName is the FileName generated as a result of the wildcard matching step.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set to DELETE (0x00010000).

  • ShareAccess is set to 0x00000000.

  • CreateOptions is set to FILE_NON_DIRECTORY_FILE.

  • CreateDisposition is set to FILE_OPEN.

  • DesiredFileAttributes is set to 0x00000000.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The file is opened as described in [MS-FSA] section 2.1.5.1, and the returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the operation is successful, the file is marked to be deleted when closed as described in [MS-FSA] section 2.1.5.14, passing the following mapping of input elements:

  • Open is the Open returned in the previous operation.

  • FileInformationClass is FileDispositionInformation. See [MS-FSA] section 2.1.5.15.3.

  • InputBuffer is the FILE_DISPOSITION_INFORMATION data element specified in [MS-FSCC]. InputBuffer.DeletePending is set to TRUE.

  • InputBufferLength is the size of the FILE_DISPOSITION_INFORMATION data element.

If the Set File Information operation fails, the Status is returned in an Error Response, and processing is complete. If the operation is successful, the Open is immediately closed, which results in the deletion of the file. All other results are ignored.

<257> Section 3.3.5.10: Windows-based servers implement wildcard file rename as a three-step process.

Step 1: Old Filename Wildcard Matching

Windows-based servers match wildcard patterns within directories as described in [MS-FSA] section 2.1.5.6. The following is a mapping of input elements:

  • Open is an Open resulting from opening the directory portion of the SMB_Data.Bytes.OldFileName field from the request.

  • FileNamePattern is the final component of the OldFileName field.

If the operation fails, the Status is returned in an Error Response, and processing is complete. Otherwise, all files that match the FileNamePattern are candidates for deletion. The next step is performed for each file that matches the wildcard pattern.

Step 2:  SearchAttribute Filtering

Windows-based servers match SearchAttributes as follows:

If both SMB_FILE_ATTRIBUTE_HIDDEN and SMB_FILE_ATTRIBUTE_SYSTEM are specified in SearchAttributes, then all files match.

If either or both of the SMB_FILE_ATTRIBUTE_HIDDEN or SMB_FILE_ATTRIBUTE_SYSTEM are not set, the server queries the object store for the attributes of the file.

  • Windows-based servers obtain FileAttributes values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open resulting from opening the FileName to be queried.

    • FileInformationClass is FileBasicInformation.

      If the open or the query fails, the file does not match and is not renamed. Otherwise:

    • All bits except the SMB_FILE_ATTRIBUTE_HIDDEN and SMB_FILE_ATTRIBUTE_SYSTEM bits are cleared from the FileAttributes returned from the query operation.

      FileAttributes &= (FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_HIDDEN)

    • If the value of FileAttributes cast to a USHORT does not exactly match SearchAttributes, the file does not match and is not renamed. Otherwise, the Open is passed to the next step.

Step 3: Rename

Windows-based servers rename files as described in [MS-FSA] section 2.1.5.15. The following is a mapping of input elements:

  • Open is an Open resulting from opening the OldFileName, as provided by the preceding steps.

  • FileInformationClass is FileRenameInformation.

  • ReplaceIfExists is FALSE.

  • RootOpen is provided by using the SMB_Header.TID to find the matching TreeConnect in the Server.Connection.TreeConnectTable, which in turn provides the Server.TreeConnect.Share.  Server.TreeConnect.Share points to an entry in the Server.Share table. The Server.Share.LocalPath is the path to the root of the share. An Open directory handle representing Server.Share.LocalPath is passed as RootOpen.

  • FileName is generated from the OldFileName and the wildcard pattern in NewFileName. A description of the wildcard mapping that produces FileName is given in [XOPEN-SMB] section 3.6.

  • FileNameLength is the length, in bytes, of the new FileName. The length includes the trailing null byte(s), if present.

The returned Status is copied into the SMB_Header.Status field of the response. The Open is closed.  All other results are ignored.

<258> Section 3.3.5.10: When opening, overwriting, deleting, or renaming a file, Windows NT Server checks for sharing violations. If a sharing violation would be generated by the operation, the server delays for 200 ms and then tests again for a sharing violation. The server retries five times, for a total delay of approximately one second, before giving up and returning the sharing violation error.

<259> Section 3.3.5.10: Windows processes any required OpLock break notification to SMB prior to deletion via the interface described in [MS-FSA] section 2.1.5.18.3 and pends the delete operation until acknowledged via the interface described [MS-FSA] section 2.1.5.19.

<260> Section 3.3.5.11: Windows-based servers obtain file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

  • Open is created by opening the file indicated by FileName in the request. If the open operation fails, the Status is returned in an Error Response and processing is complete. While opening the file, the underlying object store checks for the necessity of an OpLock break, as described in [MS-FSA] section 2.1.4.12, and if necessary, notifies the server as specified in section 3.3.4.2 and defers the opening of the file until the server acknowledges the Oplock break, as specified in section 3.3.5.30.

  • FileInformationClass is FileNetworkOpenInformation.

<261> Section 3.3.5.12: In order to set file attributes and the time of the last write to the file, Windows NT CIFS servers open the file in the object store as described in [MS-FSA] section 2.1.5.1. While opening the file, the underlying object store checks for the necessity of an OpLock break, as described in [MS-FSA] section 2.1.4.12, and if necessary, notifies the server via section 3.3.4.2 and defers the opening of the file until the server acknowledges the Oplock break, as specified in section 3.3.5.30.

Windows-based servers set the LastWriteTime of the file if the SMB_Parameters.Words.LastWriteTime field in the request is not zero or -1 (0xFFFFFFFF). Windows-based servers set this value as described in [MS-FSA] section 2.1.5.15.2, with the following mapping of input elements:

  • Open is created by opening the file indicated by FileName field in the request. If the open operation fails, the Status is returned in an Error Response, and processing is complete.

  • FileInformationClass is FileBasicInformation.

  • InputBuffer.CreationTime, InputBuffer.LastAccessTime, InputBuffer.ChangeTime, and InputBuffer.FileAttributes are all set to zero.

  • InputBuffer.LastWriteTime is set to the time value in the SMB_Parameters.Words.LastWriteTime field.

The returned Status is copied into the SMB_Header.Status field of the response. The Open is closed.  All other results are ignored.

<262> Section 3.3.5.13: Windows-based servers request a read of the file from the object store as described in [MS-FSA] section 2.1.5.3, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • ByteOffset is the SMB_Parameters.Words.ReadOffsetInBytes field of the request.

  • ByteCount is the SMB_Parameters.Words.CountOfBytesToRead field of the request.

  • IsNonCached is not used.

  • Key is set to ((Open.FID << 16) | Open.PID.PIDLow).

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is copied into the SMB_Data.Bytes.Bytes field of the response.

  • BytesRead is copied into both the SMB_Parameters.Words.CountOfBytesReturned and SMB_Data.Bytes.CountOfBytesRead fields of the response.

<263> Section 3.3.5.14: Windows-based servers request a write to a file in the object store as described in [MS-FSA] section 2.1.5.4, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • ByteOffset is the SMB_Parameters.Words.WriteOffsetInBytes field of the request.

  • ByteCount is the SMB_Parameters.Words.CountOfBytesToWrite field of the request.

  • IsWriteThrough is set to TRUE if Open.IsWriteThrough is TRUE.

  • IsNonCached is not used.

  • InputBuffer is copied from the SMB_Data.Bytes.Bytes field of the request.

  • Key is set to ((Open.FID << 16) | Open.PID.PIDLow).

The returned Status is copied into the SMB_Header.Status field of the response. If the write fails, the Status is returned in an Error Response, and processing is complete.  If the operation is successful, the following additional mapping of output elements applies:

  • BytesWritten is copied into the SMB_Parameters.Words.CountOfBytesWritten field of the response.

<264> Section 3.3.5.15: Windows-based servers request a byte-range lock from the underlying object store as described in [MS-FSA] section 2.1.5.8, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • FileOffset is the SMB_Parameters.Words.LockOffsetInBytes field of the request.

  • Length is the SMB_Parameters.Words.CountOfBytesToLock field of the request.

  • ExclusiveLock – TRUE

  • FailImmediately – FALSE, if Server.Open.LastFailedLockOffset is equal to LockOffsetInBytes field of the request. Otherwise - TRUE

  • LockKey is set to ((Open.FID << 16) | Open.PID.PIDLow).

<265> Section 3.3.5.15: The default timeout for lock violations on Windows NT CIFS servers is 250 milliseconds.

<266> Section 3.3.5.16: Windows-based servers release a byte-range lock from the underlying object store as described in [MS-FSA] section 2.1.5.9, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • FileOffset is the SMB_Parameters.Words.UnlockOffsetInBytes field of the request

  • Length is the SMB_Parameters.Words.CountOfBytesToUnlock field of the request.

  • LockKey is set to ((Open.FID << 16) | Open.PID.PIDLow).

The returned Status is copied into the SMB_Header.Status field of the response.

<267> Section 3.3.5.17: Windows-based servers create temporary files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching TreeConnect in the Server.Connection.TreeConnectTable, which in turn provides the Server.TreeConnect.Share. Server.TreeConnect.Share points to an entry in the Server.Share table. The Server.Share.LocalPath is the path to the root of the share. An Open directory handle representing Server.Share.LocalPath is passed as RootOpen.

  • PathName is created by combining the SMB_Data.Bytes.DirectoryName field from the request with a pseudo-randomly generated file name. Windows-based servers generate file names in the form SRVxxxxx, where xxxxx is a hexadecimal integer.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set to (GENERIC_READ | GENERIC_WRITE).

  • ShareAccess is set to FILE_SHARE_WRITE. If the file extension (after the '.' in the filename) is in the special filename suffix set ("EXE", "DLL", "SYM, "COM"), then ShareAccess is set to FILE_SHARE_WRITE  | FILE_SHARE_READ).

  • DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL.

  • CreateDisposition is set to FILE_CREATE.

    • If the SMB_Header.Flags2 SMB_FLAGS2_KNOWS_EAS flag is not set, then the FILE_NO_EA_KNOWLEDGE bit is also set.

  • CreateOptions is set to FILE_NON_DIRECTORY_FILE.

    • If the WritethroughMode bit of the SMB_Parameters.Words.AccessMode field is set, then the FILE_WRITE_THROUGH bit is also set.

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the operation is successful, processing continues as follows:

  • If the SMB_FLAGS_OPLOCK flag is set in the SMB_Header.Flags of the request, then an OpLock is being requested. Windows-based servers obtain OpLocks as described in [MS-FSA] section 2.1.5.18, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operation.

    • Type is LEVEL_BATCH if the SMB_FLAGS_OPBATCH flag is set in the SMB_Header.Flags of the request; otherwise, it is LEVEL_ONE.

If an OpLock is granted, the SMB_Header.Flags SMB_FLAGS_OPLOCK and SMB_FLAGS_OPBATCH flags are copied from the request to the response. Otherwise, both flags are set to zero in the response.

  • Windows-based servers ignore the SMB_Parameters.Words.CreationTime in this request.

  • A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.  The pseudo-randomly generated file name is returned as a null-terminated OEM_STRING in the SMB_Data.Bytes.TemporaryFileName field.

<268> Section 3.3.5.18: Windows-based servers process this command as an SMB_COM_CREATE request, as specified in section 3.3.5.6, with the exception that CreateDisposition is set to FILE_CREATE instead of FILE_OVERWRITE_IF.

<269> Section 3.3.5.19: Windows-based servers obtain file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

  • Open is created by opening the DirectoryName in the request as a directory. If the open operation fails, the Status is returned in an Error Response and processing is complete.

  • FileInformationClass is FileNetworkOpenInformation.

The returned Status is copied into the SMB_Header.Status field of the response. Success indicates that the DirectoryName is the name of an existing directory.

<270> Section 3.3.5.20: Windows-based servers close an existing Open in the object store as described in [MS-FSA] section 2.1.5.5, Server Requests Closing an Open. Any Oplocks held by the Open are cleaned up as described in Phase 8 -- Oplock Cleanup in [MS-FSA] section 2.1.5.5.

<271> Section 3.3.5.20: Windows NT Server 4.0 does not use the header CID field as a lookup key. The list of pending requests is associated with the SMB transport, so the effect is the same.

<272> Section 3.3.5.21: Windows-based servers query file information from the object store as described in [MS-FSA] section 2.1.5.12. Windows-based servers set information on files in the object store as described in [MS-FSA] section 2.1.5.15. File position can be set or retrieved with the following mapping of input elements:

Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

FileInformationClass is FilePositionInformation.

If SMB_Parameters.Words.Mode is 0x0000, the new current position is set; next, InputBuffer.CurrentByteOffset (see [MS-FSA] section 2.1.5.15.9) is set to SMB_Parameters.Words.Offset.

If SMB_Parameters.Words.Mode is 0x0001, the CurrentByteOffset is read by sending a query (see [MS-FSA] section 2.1.5.12.23). The OutputBuffer.CurrentByteOffset is then added to SMB_Parameters.Words.Offset, and the result is stored in InputBuffer.CurrentByteOffset.

If SMB_Parameters.Words.Mode is 0x0001, the file size is read by setting FileInformationClass to FileStandardInformation. SMB_Parameters.Words.Offset is then subtracted from OutputBuffer.EndOfFile. The result is stored in InputBuffer.CurrentByteOffset. FileInformationClass is reset to FilePositionInformation.

The new file position is then set as described in [MS-FSA] section 2.1.5.15. The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete. If the operation is successful, the InputBuffer.CurrentByteOffset is copied to the SMB_Paramters.Words.Offset field of the response.

<273> Section 3.3.5.22: Windows-based servers process this command as if it were an SMB_COM_LOCK_BYTE_RANGE (section 2.2.4.13) followed by an SMB_COM_READ (section 2.2.4.11). See the behavior notes in sections 3.3.5.15 and 3.3.5.13.

<274> Section 3.3.5.23: With one exception, Windows-based servers process this command as if it were an SMB_COM_WRITE followed by an SMB_COM_UNLOCK_BYTE_RANGE. See the behavior notes for sections 3.3.5.14 and 3.3.5.16. The exception is that the write and unlock requests are passed to the underlying file system in a single step.

<275> Section 3.3.5.24: Windows-based servers request a raw read of the file from the object store, as described in [MS-FSA] section 2.1.5.3, with the following mapping of input elements:

  • Open is the Open indicated by the  SMB_Parameters.Words.FID field of the request.

  • ByteOffset is the SMB_Parameters.Words.ReadOffsetInBytes field of the request.

  • ByteCount is the SMB_Parameters.Words.CountOfBytesToRead field of the request.

  • IsNonCached is not used.

  • Key is set to ((Open.FID << 16) | Open.PID.PIDLow).

Due to this command's not returning an SMB message as a response, the Status field is not sent to the client in the event of an error. If Status indicates an error, the server simply sends a zero-length response to the client. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is the raw data to be sent to the client over the SMB transport.

  • BytesRead is not used

<276> Section 3.3.5.24: Windows-based servers ignore the Timeout field.

<277> Section 3.3.5.25: Windows-based servers request a multiplexed read of the file from the object store as described in [MS-FSA] section 2.1.5.3, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • ByteOffset is the SMB_Parameters.Words. Offset field of the request.

  • ByteCount is the SMB_Parameters.Words.MaxCountOfBytesToReturn field of the request.

  • IsNonCached is not used.

  • Key is set to ((Open.FID << 16) | Open.PID.PIDLow).

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is divided among the SMB_Data.Bytes.Data fields of however many responses that the server needs to send to the client to complete the operation.

  • BytesRead: The sum of all the SMB_Parameters.Words.DataLength fields across however many responses that the server needs to send add up to this value.

<278> Section 3.3.5.25: Windows NT and Windows 98 clients and Windows NT Server support this command on connectionless transports only. In particular, clients can send this command only over the Direct IPX Transport. Windows NT Server does not support the use of SMB_COM_READ_MPX to read from named pipes or I/O devices. Server support for this command is indicated by the CAP_MPX_MODE Capability bit in the SMB_COM_NEGOTIATE response.

<279> Section 3.3.5.25: Windows-based servers ignore the Timeout field.

<280> Section 3.3.5.26: Windows NT servers do not validate the DataOffset field value.

<281> Section 3.3.5.26: If raw mode data buffers or other resources are not available, Windows NT Server fails the SMB_COM_WRITE_RAW request without writing the initial data. Likewise, if the FID represents a named pipe or device, the write operation might block, and if there are insufficient resources to buffer the data while waiting to write it, Windows NT fails the request without writing the initial data.

<282> Section 3.3.5.26: Windows-based servers ignore the Timeout field.

<283> Section 3.3.5.26: [XOPEN-SMB] specifies that if all of the data to be written is contained in the initial request, the server has to send an Interim Server Response and the client has to send a zero-length raw write. Older clients can exhibit that behavior. Windows NT Server, however, behaves as specified in section 3.3.5.26 of this document. If all of the data was transferred in the initial request, the NT server sends a Final Server Response indicating that the entire write operation has been completed.

<284> Section 3.3.5.28: Windows-based servers obtain file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • FileInformationClass is FileNetworkOpenInformation.

If the query fails, the Status is returned in an Error Response and processing is complete.  Otherwise, the response message fields are populated as follows:

  • The SMB_DATE and SMB_TIME fields in the SMB_Parameters.Words block of the response are set by converting the FILETIME fields with matching names to SMB_DATE/SMB_TIME format.

    • CreateDate and CreationTime are derived from OutputBuffer.CreationTime.

    • LastAccessDate and LastAccessTime are derived from OutputBuffer.LastAccessTime.

    • LastWriteDate and LastWriteTime are derived from OutputBuffer.LastModificationTime.

    • OutputBuffer.ChangeTime is not returned to the client.

  • SMB_Parameters.Words.FileDataSize is set to OutputBuffer.EndOfFile.

  • SMB_Parameters.Words. FileAllocationSize is set to OutputBuffer.AllocationSize.

  • SMB_Parameters.Words.FileAttributes is set by converting OutputBuffer.FileAttributes from the 32-bit SMB_EXT_FILE_ATTR format to the 16-bit SMB_FILE_ATTRIBUTE format (see sections 2.2.1.2.4 and 2.2.1.2.3).

     FileAttributes &= ( SMB_FILE_ATTRIBUTE_READONLY |
                     SMB_FILE_ATTRIBUTE_HIDDEN   |
                     SMB_FILE_ATTRIBUTE_SYSTEM   |
                     SMB_FILE_ATTRIBUTE_ARCHIVE  |
                     SMB_FILE_ATTRIBUTE_DIRECTORY )
 

<285> Section 3.3.5.29: Windows-based servers set file information from the object store as described in [MS-FSA] section 2.1.5.15, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • FileInformationClass is set to FileBasicInformation.

  • The SMB_DATE and SMB_TIME fields in the SMB_Parameters.Words block of the request are converted to FILETIME fields with matching names to SMB_DATE/SMB_TIME format:

    • CreateDate and CreationTime are converted and copied to InputBuffer.CreationTime.

    • LastAccessDate and LastAccessTime are converted and copied to InputBuffer.LastAccessTime.

    • LastWriteDate and LastWriteTime are converted and copied to OutputBuffer.LastModificationTime.

    • InputBuffer.ChangeTime is set to zero (0).

The Status returned is copied into the SMB_Header.Status field of the response.

<286> Section 3.3.5.30: If an SMB_COM_LOCKING_ANDX Request has a nonzero NumberOfRequestedUnlocks field, Windows-based servers release a byte-range lock from the underlying object store as described in [MS-FSA] section 2.1.5.9, with the following mapping of input elements for each element "X" in the SMB_Data.Bytes.Unlocks array:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • FileOffset is the Unlocks[X].ByteOffset field of the request for LOCKING_RANGE_ANDX32, or Unlocks[X].ByteOffsetHigh and Unlocks[X].ByteOffsetLow for LOCKING_ANDX_RANGE64.

  • Length is the Unlocks[X].LengthInBytes field of the request for LOCKING_RANGE_ANDX32, or Unlocks[X].LengthInBytesHigh and Unlocks[X].LengthInBytesLow for LOCKING_ANDX_RANGE64.

Either the first returned Status indicating an error or the final returned success Status is copied into the SMB_Header.Status field of the response.

<287> Section 3.3.5.30: If an SMB_COM_LOCKING_ANDX Request has a nonzero  NumberOfRequestedLocks field, Windows-based servers request a byte-range lock from the underlying object store as described in [MS-FSA] section 2.1.5.8, with the following mapping of input elements for each element "X" in the SMB_Data.Bytes.Locks array:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • FileOffset is the Locks[X].ByteOffset field of the request for LOCKING_RANGE_ANDX32, or Locks[X].ByteOffsetHigh and Locks[X].ByteOffsetLow for LOCKING_ANDX_RANGE64.

  • Length is the Locks[X].LengthInBytes field of the request for LOCKING_RANGE_ANDX32, or Locks[X]. LengthInBytes High and Locks[X].LengthInBytes Low for LOCKING_ANDX_RANGE64.

  • ExclusiveLock is TRUE if SMB_Parameters.Words.TypeOfLock indicates READ_WRITE_LOCK, or FALSE if it indicates SHARED_LOCK.

  • FailImmediately is TRUE if SMB_Parameters.Words.Timeout is zero, or FALSE if Timeout is nonzero.

  • LockKey is set to ((Open.FID << 16) | Open.PID.PIDLow).

<288> Section 3.3.5.30: Windows-based servers process the Oplock break acknowledgment by invoking [MS-FSA] section 2.1.5.19 with the following mapping of input elements: Open is the Open indicated by the SMB_Parameters.Words.FID field of the request. Type is the resultant Oplock level from Server.Open.Oplock.

<289> Section 3.3.5.30: Windows NT Server do not test whether NumberOfRequestedUnlocks is nonzero in an OpLock Break Request message.

<290> Section 3.3.5.30: Windows-based servers acknowledge an OpLock break as described in [MS-FSA] section 2.1.5.19, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • Type is LEVEL_TWO.

<291> Section 3.3.5.30:  After failing the lock byte range request with STATUS_LOCK_NOT_GRANTED, if a client attempts to lock the same range of locked bytes, subranges, or overlapping ranges, Windows-based servers fail the lock request with STATUS_FILE_LOCK_CONFLICT (ERRDOS/ERRlock).

<292> Section 3.3.5.32: Windows NT servers support a specific set of IOCTL requests (see the notes in section 2.2.4.35). The IOCTL requests were originally defined by the OS/2 operating system.

The following table provides a mapping of OS/2 IOCTL request to Windows NT server actions. See [MSDN-SDCTRLREQSTS] for more information on Serial Device Control Requests.

Category

OS/2 IOCTL function

Action

SERIAL_DEVICE0x0001

GET_BAUD_RATE0x0061

NtDeviceIoControlFile() is called with IoControlCode set to IOCTL_SERIAL_GET_BAUD_RATE.

SERIAL_DEVICE0x0001

SET_BAUD_RATE0x0041

NtDeviceIoControlFile() is called with IoControlCode set to IOCTL_SERIAL_SET_BAUD_RATE.

SERIAL_DEVICE0x0001

GET_LINE_CONTROL0x0062

NtDeviceIoControlFile() is called with IoControlCode set to IOCTL_SERIAL_GET_LINE_CONTROL.

SERIAL_DEVICE0x0001

SET_LINE_CONTROL0x0042

NtDeviceIoControlFile() is called with IoControlCode set to IOCTL_SERIAL_SET_LINE_CONTROL.

SERIAL_DEVICE0x0001

GET_DCB_INFORMATION0x0073

NtDeviceIoControlFile() is called with IoControlCode set to IOCTL_SERIAL_GET_TIMEOUTS.

SERIAL_DEVICE0x0001

SET_DCB_INFORMATION0x0053

Windows NT Server returns STATUS_SUCCESS without processing the IOCTL. The IOCTL response returns no Parameters or Data.

SERIAL_DEVICE0x0001

GET_COMM_ERROR0x006D

Windows NT Server returns STATUS_SUCCESS without processing the IOCTL. The IOCTL response returns no Parameters or Data.

SERIAL_DEVICE0x0001

SET_TRANSMIT_TIMEOUT0x0044

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

SET_BREAK_OFF0x0045

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

SET_MODEM_CONTROL0x0046

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

SET_BREAK_ON0x004B

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

STOP_TRANSMIT0x0047

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

START_TRANSMIT0x0048

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_COMM_STATUS0x0064

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_LINE_STATUS0x0065

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_MODEM_OUTPUT0x0066

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_MODEM_INPUT0x0067

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_INQUEUE_COUNT0x0068

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_OUTQUEUE_COUNT0x0069

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

GET_COMM_EVENT0x0072

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

SERIAL_DEVICE0x0001

Any other value.

Windows NT Server returns an error response with Status of STATUS_INVALID_PARAMETER.

PRINTER_DEVICE0x0005

GET_PRINTER_STATUS0x0066

Windows NT Server returns STATUS_SUCCESS without processing the IOCTL. The IOCTL response returns only one Data byte, which contains an OS/2 printer status code of 0x90 (OS2_STATUS_PRINTER_HAPPY).

SPOOLER_DEVICE0x0053

GET_PRINTER_ID0x0060

Windows NT Server stores the JobID as an attribute of the printer file Open. The share name is an attribute of the TreeConnect (Server.TreeConnect.Share->Share.ShareName) and server name is the configured name of the server. These values are returned in the response.

GENERAL_DEVICE0x000B

Windows NT Server returns an error response with Status of STATUS_NOT_IMPLEMENTED.

<293> Section 3.3.5.33: Windows 98 accepts only an SMB_COM_ECHO request containing a valid TID or a TID value of 0xFFFF (-1). Windows NT systems ignore the TID in the SMB_COM_ECHO request.

<294> Section 3.3.5.34: Windows-based servers process this command as if it were an SMB_COM_WRITE (section 2.2.4.12) followed by an SMB_COM_CLOSE (section 2.2.4.5). See the product behavior notes for sections 3.3.5.14 and 3.3.5.7.

<295> Section 3.3.5.35: Windows NT Server always ignores the FileAttrs field and the SearchAttrs field on Open and Create operations, and searches for files by name only.

<296> Section 3.3.5.35: Windows-based servers permit the file creation, if the FileExistsOpts flag value is 0 and the AccessMode.SharingMode field value is 1, 2, 3, or 4.

<297> Section 3.3.5.35: Windows-based servers open files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

  • PathName is the SMB_Data.Bytes.FileName field from the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • UserCertificate is empty.

  • DesiredAccess is set as follows:

    • The AccessMode subfield of the AccessMode field in the request is used to set the value of DesiredAccess. The AccessMode subfield represents the lowest-order four bits of the AccessMode field (0x0007), as shown in the table in section 2.2.4.3.1. The mapping of values is as follows.

    AccessMode.AccessMode

    DesiredAccess

    0

    GENERIC_READ 0x80000000

    1

    GENERIC_WRITE | FILE_READ_ATTRIBUTES 0x40000000 | 0x00000080

    2

    GENERIC_READ | GENERIC_WRITE 0x80000000 | 0x40000000

    3

    GENERIC_READ | GENERIC_EXECUTE 0x80000000 | 0x20000000

    For any other value of AccessMode.AccessMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).

  • ShareAccess is set as follows:

    • The SharingMode subfield of the AccessMode field in the request is used to set the value of ShareAccess. The SharingMode subfield is a 4-bit subfield of the AccessMode field (0x0070), as shown in the table in section 2.2.4.3.1. The mapping of values is as follows.

    AccessMode.SharingMode

    ShareAccess

    0

    Compatibility mode (see below)

    1

    0x0L (don't share, exclusive use)

    2

    FILE_SHARE_READ

    3

    FILE_SHARE_WRITE

    4

    FILE_SHARE_READ | FILE_SHARE_WRITE

    • For Compatibility mode, special filename suffixes (after the '.' in the filename) are mapped to SharingMode 4. The special filename suffix set is: "EXE", "DLL", "SYM", and "COM". All other file names are mapped to SharingMode 3.

    • If AccessMode field in the request is 0xFF, and the file is already open on the server, the current sharing mode of the existing Open is preserved, and a FID for the file is returned. If the file is not already open on the server, the server attempts to open the file using SharingMode 1.

    • For any other value of AccessMode.SharingMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).

    • CreateOptions bits are set as follows.

    CreateOptions value

    SMB_COM_OPEN_ANDX equivalent

    FILE_WRITE_THROUGH

    AccessMode.WritethroughMode == 1

    FILE_SEQUENTIAL_ONLY

    AccessMode.ReferenceLocality == 1

    FILE_RANDOM_ACCESS

    AccessMode.ReferenceLocality == 2 or AccessMode.ReferenceLocality == 3

    FILE_NO_INTERMEDIATE_BUFFERING

    AccessMode.CacheMode == 1

    FILE_NON_DIRECTORY_FILE

    Is set

    FILE_COMPLETE_IF_OPLOCKED

    Is set

    FILE_NO_EA_KNOWLEDGE

    SMB_Header.Flags2.SMB_FLAGS2_KNOWS_EAS == 0

    • All other bits are unused.

    • CreateDisposition is set as follows.

    CreateDisposition value

    SMB_Parameters.Word.OpenMode equivalent

    Invalid combination; return STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess)

    FileExistsOpts = 0 & CreateFile = 0

    FILE_CREATE

    FileExistsOpts = 0 & CreateFile = 1

    FILE_OPEN

    FileExistsOpts = 1 & CreateFile = 0

    FILE_OPEN_IF

    FileExistsOpts = 1 & CreateFile = 1

    FILE_OVERWRITE

    FileExistsOpts = 2 & CreateFile = 0

    FILE_OVERWRITE_IF

    FileExistsOpts = 2 & CreateFile = 1

While opening an existing file, the underlying object store checks for the necessity of an OpLock break, as described in [MS-FSA] section 2.1.4.12, and if necessary, notifies the server as specified in section 3.3.4.2 and defers the opening of the file until the server acknowledges the OpLock break, as specified in section 3.3.5.30.

<298> Section 3.3.5.35: When opening, overwriting, deleting, or renaming a file, Windows NT Server checks for sharing violations. If a sharing violation would be generated by the operation, the server delays for 200 ms and then tests again for a sharing violation. The server retries five times, for a total delay of approximately one second, before giving up and returning the sharing violation error.

<299> Section 3.3.5.36: Windows-based servers request a read of the file from the object store as described in [MS-FSA] section 2.1.5.3, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID. field of the request.

  • ByteOffset is either the 32- or 64-bit offset, as determined by the server.

  • ByteCount is the SMB_Parameters.Words.MaxCountOfBytesToReturn field of the request.

  • IsNonCached is not used.

  • Key is set to ((Open.FID << 16) | Open.PID.PIDLow).

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is copied into the SMB_Data.Bytes.Data field of the response.

  • BytesRead is copied into the SMB_Parameters.Words.DataLength field of the response.

<300> Section 3.3.5.36: Windows-based servers ignore the Timeout field. Reads from named pipes and I/O devices will always block until MinCountOfBytesToReturn are read.

<301> Section 3.3.5.37: Windows NT servers do not validate the DataOffset field value.

<302> Section 3.3.5.37: Windows NT based servers do not fail the request; instead, they write only SMB_Parameters.Words.DataLength bytes from the SMB_Data.Bytes.Data field to the target file.

<303> Section 3.3.5.37: Windows-based servers ignore the Timeout field. Writes to named pipes or I/O devices always block until the number of DataLength bytes are written.

<304> Section 3.3.5.37: If the Remaining field is nonzero, and if the MSG_START bit is set in the SMB_Parameters.Words.WriteMode field, Windows-based servers ignore the first two bytes of the SMB_Data.Bytes.Data field.

<305> Section 3.3.5.37: Windows-based servers request a write to a file in the object store as described in [MS-FSA] section 2.1.5.4, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • ByteOffset is the SMB_Parameters.Words.Offset field of the request.

  • ByteCount is the SMB_Parameters.Words.DataLength field of the request.

  • IsWriteThrough is the SMB_Parameters.Words.WriteMode.WritethroughMode bit of the request.

  • IsNonCached is not used.

  • InputBuffer is copied from the SMB_Data.Bytes.Data field of the request.

  • Key is set to ((Open.FID << 16) | Open.PID.PIDLow).

The returned Status is copied into the SMB_Header.Status field of the response. If the write fails, the Status is returned in an Error Response and processing is complete. If the operation is successful, the following additional mapping of output elements applies:

  • BytesWritten is copied into the SMB_Parameters.Words.Count field of the response.

<306> Section 3.3.5.40: Windows implementations check to see if the user indicated by the Server.Session.UserSecurityContext identified by the SMB_Header.UID is a member of the Administrator group.

<307> Section 3.3.5.45: Windows implementations check to see if the user indicated by the Server.Session.UserSecurityContext identified by the SMB_Header.UID is a member of the Administrator group.

<308> Section 3.3.5.45: Windows-based servers do not fail tree connects to non-administrative shares by users that are not granted access but will fail attempts by those clients to open or create files. Windows-based servers will fail tree-connect requests to administrative shares, such as C$ or D$, that are issued by a non-administrator.

<309> Section 3.3.5.46: Windows-based servers obtain volume information from the object store as described in [MS-FSA] section 2.1.5.13, with the following mapping of input elements:

  • Open is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as Open.

  • FsInformationClass is set to FileFsSizeInformation.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete. If the operation is successful, the information returned in OutputBuffer is adjusted to fit within the data structure provided by SMB.

All of the fields in the SMB_COM_QUERY_INFORMATION_DISK Response (section 2.2.4.57.2) are 16-bit, but the FileFsSizeInformation InformationLevel provides 32- and 64-bit values.  The goal is to adjust the values so that the total bytes on disk and the total number of available (free) bytes can be calculated reasonably correctly from the numbers returned.

  • The value of Output.TotalAllocationUnits is divided by two (bitshifted) until the result fits within a USHORT (16 bits, unsigned); that is, until the result is less than 0x00010000.  The number of bit shifts is counted and stored as HighBits and also as ExtraBits. If the value of HighBits is greater than zero, the value of Output.SectorsPerAllocationUnit is multiplied by two, and HighBits is decremented. This is repeated until HighBits is zero or the result of the multiplication is greater than or equal to 0x8000. The result is copied into SMB_Parameters.Words.BlocksPerUnit.

  • If the value of HighBits is still greater than zero, the value of Output.BytesPerSector is multiplied by two and HighBits is decremented. This is repeated until HighBits is zero or the result of the multiplication is greater than or equal to 0x8000. The result is copied into SMB_Parameters.Words.BlockSize.

  • If the value of HighBits is still greater than zero, SMB_Parameters.Words.TotalUnits is set to the largest possible value: 0xFFFF. Otherwise, SMB_Parameters.Words.TotalUnits is calculated as (Output.TotalAllocationUnits / (2 × ExtraBits)).

  • SMB_Parameters.Words.FreeUnits is calculated as (Output.ActualAvailableAllocationUnits / (2 × (ExtraBits –HighBits))). If the result of the calculation is greater than 0xFFFF, SMB_Parameters.Words.FreeUnits is set to 0xFFFF.

The SMB_Header.Status field of the response is set to Success.

<310> Section 3.3.5.47: Windows NT Server 4.0 returns STATUS_NO_MORE_FILES for an empty string in the FileName field of the SMB_COM_SEARCH (section 2.2.4.58) request.

<311> Section 3.3.5.47: Windows NT Server uses both of these techniques.

<312> Section 3.3.5.47: If the SMB_FILE_ATTRIBUTE_VOLUME bit is set--and is the only bit set--in the SMB_Parameters.Words.SearchAttributes field in the request, Windows-based servers return the volume name of the volume underlying the share indicated by SMB_Header.TID. Volume information is queried as described in [MS-FSA] section 2.1.5.13. The following is a mapping of input elements:

  • Open is an Open resulting from opening the directory portion of the SMB_Data.Bytes.FileName field from the request.

  • FileInformationClass is set to FileFsVolumeInformation.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, Status is returned in an Error Response, and processing is complete; otherwise, a single DirectoryInformationData[] field entry is returned in the SMB_Data.Bytes block of the response:

  • The FileAttributes field is set to SMB_FILE_ATTRIBUTE_VOLUME.

  •  The LastWriteTime, LastWriteDate, and FileSize fields are set to zero.

  • The OutputBuffer.VolumeLabel is converted to the OEM character set and copied into the FileName field. At most, 11 bytes of the volume label are copied. If the volume label is greater than 8 bytes in length, a dot (".") is inserted between the 8th and 9th characters. Unused bytes are space-padded.

  • The SMB_Header.Status field of the response is set to Success.

If the SMB_Parameters.Words.SearchAttributes field in the request is not equal to SMB_FILE_ATTRIBUTE_VOLUME, Windows-based servers proceed with a normal directory lookup.

Windows-based servers search directories for files with names that match wildcard patterns as described in [MS-FSA] sections 2.1.5.6 and 2.1.5.6.3. The following is a mapping of input elements:

  • Open is an Open resulting from opening the directory portion of the SMB_Data.Bytes.FileName field from the request.

  • FileInformationClass is set to FileBothDirectoryInformation.

  • OutputBufferSize is large enough to hold at least one  FILE_BOTH_DIR_INFORMATION ([MS-FSCC] section 2.4.8) structure.

  • RestartScan is FALSE.

  • ReturnSingleEntry is FALSE.

  • If the SMB_Data.Bytes.ResumeKeyLength field is zero, then this is a new search, and FileIndex is not used; otherwise, the SMB_Data.Bytes.ResumeKey field is used to set FileIndex so that the directory search continues sequentially.

  • FileNamePattern is the final component of the FileName field.

If the directory search operation fails:

  • If Status is returned as STATUS_NO_SUCH_FILE, Status is set to STATUS_NO_MORE_FILES to indicate that the search has completed.

  • If Status is returned as STATUS_NO_MORE_FILES, Status is set to STATUS_OBJECT_PATH_NOT_FOUND because the SMB_Data.Bytes.FileName field in the request provided a complete path.

  • The Status is copied to the SMB_Header.Status field and returned in an Error Response. Processing is complete.

If the search operation succeeds, the OutputBuffer.FileAttributes of each entry in the list of files returned is compared against the SMB_Parameters.Words.SearchAttributes field in the request as follows:

  • The SMB_FILE_ATTRIBUTE_VOLUME bit is ignored.

  • If OutputBuffer.FileAttributes has FILE_ATTRIBUTE_HIDDEN set, but SMB_FILE_ATTRIBUTE_HIDDEN is not set in the SMB_Parameters.Words.SearchAttributes field, the entry is rejected.

  • If OutputBuffer.FileAttributes has FILE_ATTRIBUTE_SYSTEM set, but SMB_FILE_ATTRIBUTE_SYSTEM is not set in the SMB_Parameters.Words.SearchAttributes field, the entry is rejected.

  • If OutputBuffer.FileAttributes has FILE_ATTRIBUTE_DIRECTORY set, but  SMB_FILE_ATTRIBUTE_DIRECTORY is not set in the  SMB_Parameters.Words.SearchAttributes field, the entry is rejected.

  • If there is no short name (8.3 format name) for this file, the entry is rejected.

  • If there are exclusive bits set in the SMB_Parameters.Words.SearchAttributes field, the following additional tests are performed:

    • If SMB_SEARCH_ATTRIBUTE_READONLY is set in SearchAttributes, but FILE_ATTRIBUTE_READONLY is not set in OutputBuffer.FileAttributes, the entry is rejected.

    • If SMB_SEARCH_ATTRIBUTE_HIDDEN is set in SearchAttributes, but FILE_ATTRIBUTE_HIDDEN is not set in OutputBuffer.FileAttributes, the entry is rejected.

    • If SMB_SEARCH_ATTRIBUTE_SYSTEM is set in SearchAttributes, but FILE_ATTRIBUTE_SYSTEM is not set in OutputBuffer.FileAttributes, the entry is rejected.

    • If SMB_SEARCH_ATTRIBUTE_ARCHIVE is set in SearchAttributes, but FILE_ATTRIBUTE_ARCHIVE is not set in OutputBuffer.FileAttributes, the entry is rejected.

    • If SMB_SEARCH_ATTRIBUTE_DIRECTORY is set in SearchAttributes, but FILE_ATTRIBUTE_DIRECTORY is not set in OutputBuffer.FileAttributes, the entry is rejected.

If the entry has not been rejected, the required OutputBuffer fields are converted into the field formats used by the SMB_Directory_Information structure, described in section 2.2.4.58.2. A DirectoryInformationData[] field entry is added to the response message buffer, and the SMB_Parameters.Words.Count field is incremented to indicate the total number of DirectoryInformationData[] field entries in the response message.

  • If the SMB_Parameters.Words.Count field is equal to the maximum number of entries to return:

    • The SMB_Data.Bytes.BufferFormat field is set to 0x05.

    • The SMB_Data.Bytes.DataLength field is set to the total number of bytes copied into the DirectoryInformationData[] field array, which is 43 × SMB_Parameters.Words.Count.

    • The ResumeKey field of the final DirectoryInformationData[] field entry to be placed into the response buffer is calculated and copied into the ResumeKey field of that entry.

    • The SMB_Header.Status field is set to Success, and processing is complete.

  • The maximum number of entries to return is the minimum of:

    • The value of the SMB_Parameters.Words.MaxCount field in the request.

    • The maximum number of DirectoryInformationData[] field entries that will fit in the SMB_Data.Bytes block of the response, based upon the Server.Connection.ClientMaxBufferSize ADM element. (The size of the response with no DirectoryInformationData[] entries is 40 bytes.)

If the maximum number of entries to return has not been reached, additional entries returned in OutputBuffer are processed as described preceding. If there are no additional entries in OutputBuffer, another directory query is executed, with the value of FileIndex set to the FileIndex at the end of the previous query. If Status is returned as STATUS_NO_MORE_FILES, Status is set to Success, and processing is complete. In this way, directory entries are enumerated sequentially until there are either enough entries in the DirectoryInformationData[] field to complete the request, or there are no more entries to be added.

<313> Section 3.3.5.48: Processing of this command is identical to the processing of the SMB_COM_FIND request with SMB_Parameters.Words.MaxCount set to 0x0001.

<314> Section 3.3.5.51: This is dependent upon the underlying file system. On Windows NT Server, if the request to create a file is performed on a Windows FAT or FAT32 file system, the request fails with STATUS_ACCESS_DENIED. Otherwise it fails with STATUS_PRIVILEGE NOT HELD.

<315> Section 3.3.5.51: Windows NT servers allow only the FILE_OPEN option on a named pipe. All other options are ignored and considered the same as FILE_OPEN. When the object in question is a disk object, all options are valid.

<316> Section 3.3.5.51: Windows-based servers open files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided in one of two ways:

    • If the SMB_Parameters.Words.RootDirectoryFID field is zero, RootOpen is provided by using the SMB_Header.TID field to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on the Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

    • If the SMB_Parameters.Words.RootDirectoryFID field is non-zero, RootOpen is provided by looking up the RootDirectoryFID field in the Server.Connection.FileOpenTable.

  • PathName is the SMB_Data.Bytes.FileName field of the request.

  • SecurityContext is found by using the SMB_Header.UID field to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • UserCertificate is empty.

  • DesiredAccess is the SMB_Parameters.Words.DesiredAccess field of the request. The FILE_READ_ATTRIBUTES option is added (using a bitwise OR) to the set provided by the client. If the FILE_NO_INTERMEDIATE_BUFFERING flag is set, it is cleared, and FILE_WRITE_THROUGH is set.

  • ShareAccess is the SMB_Parameters.Words.ShareAccess field of the request.

  • CreateOptions is the SMB_Parameters.Words.CreateOptions field of the request. The FILE_COMPLETE_IF_OPLOCKED option is added (using a bitwise OR) to the set provided by the client. If the FILE_NO_INTERMEDIATE_BUFFERING flag is set, it is cleared, and FILE_WRITE_THROUGH is set.

  • CreateDisposition is the SMB_Parameters.Words.CreateDisposition field of the request.

  • DesiredFileAttributes is the SMB_Parameters.Words.ExtFileAttributes field of the request.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure in [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the operation is successful, processing continues as follows:

  • If either the NT_CREATE_REQUEST_OPLOCK or the NT_CREATE_REQUEST_OPBATCH flag is set in the SMB_Parameters.Words.Flags field of the request, an OpLock is requested. Windows-based servers obtain OpLocks as described in [MS-FSA] section 2.1.5.18, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operation.

    • Type is LEVEL_BATCH if the NT_CREATE_REQUEST_OPBATCH flag is set, or LEVEL_ONE if the NT_CREATE_REQUEST_OPLOCK flag is set.

      If an OpLock is granted, the SMB_Parameters.Words.OpLockLevel field of the response is set.

  • Windows-based servers obtain the extended file attribute and timestamp response information by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileBasicInformation ([MS-FSCC] section 2.4.7).

      If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • SMB_Parameters.Words.ExtFileAttributes is set to OutputBuffer.FileAttributes.

    • SMB_Parameters.Words.CreateTime is set to OutputBuffer.CreateTime.

    • SMB_Parameters.Words.LastAccessTime is set to OutputBuffer.LastAccessTime.

    • SMB_Parameters.Words.LastWriteTime is set to OutputBuffer.LastWriteTime.

    • SMB_Parameters.Words.LastChangeTime is set to OutputBuffer.ChangeTime.

  • Windows-based servers obtain the file size response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileStandardInformation ([MS-FSCC] section 2.4.45).

      If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • SMB_Parameters.Words.AllocationSize is set to OutputBuffer.AllocationSize.

    • SMB_Parameters.Words.EndOfFile is set to OutputBuffer.EndOfFile.

      If the query fails, the Status is returned in an Error Response, and processing is complete.

  • Open.File.FileType is used to set the SMB_Parameters.Words.ResourceType and SMB_Parameters.Words.Directory fields of the response.

  • If Open.File.FileType indicates a named pipe, Windows-based servers perform two queries for named pipe state on the underlying object store, each with different information levels, as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request that is used for both queries.

    • FileInformationClass is FilePipeInformation ([MS-FSCC] section 2.4.36) for one query and FilePipeLocalInformation for the other ([MS-FSCC] section 2.4.37).

    • OutputBufferSize is 8 bytes for the FilePipeInformation buffer (size of FILE_PIPE_INFORMATION data), and 40 bytes for the FilePipeLocalInformation buffer (size of FILE_PIPE_LOCAL_INFORMATION data).

      If either query returns an error status in Status, that value is set as the SMB_Header.Status field of the response message. If both return success, a success status is used, and the following additional mapping of output elements applies:

    • OutputBuffer: The output buffers from both queries are used to construct an SMB_NMPIPE_STATUS (section 2.2.1.3) data type. The SMB_NMPIPE_STATUS buffer is copied into the SMB_Parameters.Words.NMPipeState field of the response.

    • ByteCount is not used.

  • A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.

While opening an existing file, the underlying object store checks for the necessity of an Oplock break, as described in [MS-FSA] section 2.1.4.12, and if necessary, notifies the server as described in section 3.3.4.2 and defers the opening of the file until the server acknowledges the Oplock break, as described in section 3.3.5.30.

<317> Section 3.3.5.52: Windows NT Server 4.0 does not use the CID as a lookup key. The list of pending requests is associated with the SMB transport, so the effect is the same.

<318> Section 3.3.5.52: Windows-based servers cancel object store operations, as described in the Server Requests Canceling an Operation section in [MS-FSA], with the following mapping of input elements:

  • IORequest is the IORequest of the pending object store operation that is being canceled.

<319> Section 3.3.5.53: Windows NT servers do not completely implement the obsolete SMB_NT_RENAME_MOVE_FILE information level. Instead of returning an error, Windows NT servers perform a file copy.

<320> Section 3.3.5.53: Windows-based servers add link names to files as described in [MS-FSA] section 2.1.5.15, with the following mapping of input elements:

  • Open is created by opening the file indicated by SMB_Data.Bytes.NewFileName in the request. If the open operation fails, the Status is returned in an Error Response, and processing is complete.  The minimum access required in order to add a link to the file is (READ_CONTROL | FILE_READ_DATA | FILE_READ_ATTRIBUTES | FILE_READ_EA).

  • FileInformationClass is FileLinkInformation.

  • InputBuffer.FileName is copied from SMB_Data.Bytes.NewFileName.

The returned Status is copied into the SMB_Header.Status field of the response.  If the operation fails, the Status is returned in an Error Response.

<321> Section 3.3.5.53: When opening, overwriting, deleting, hard linking, or renaming a file, Windows NT Server checks for sharing violations. If a sharing violation would be generated by the operation, the server delays for 200 ms and then tests again for a sharing violation. The server retries five times, for a total delay of approximately one second, before giving up and returning the sharing violation error.

<322> Section 3.3.5.53: It is uncertain how Windows-based servers respond when a hard linking operation interferes with an ongoing search or other operations.

<323> Section 3.3.5.54: Windows-based servers open printer spool files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

  • PathName is "\", which indicates the root of the share.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is (GENERIC_WRITE | FILE_READ_ATTRIBUTES).

  • ShareAccess is not FILE_SHARE_READ.

  • CreateOptions is set to (FILE_NON_DIRECTORY_FILE | FILE_SEQUENTIAL_ONLY | FILE_COMPLETE_IF_OPLOCKED). If the SMB_Header.Flags2 SMB_FLAGS2_KNOWS_EAS flag is not set, then the FILE_NO_EA_KNOWLEDGE bit is also set.

  • CreateDisposition is set to FILE_OVERWRITE_IF.

  • DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request. Otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response.  If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the command is successful, the server allocates an Open object and inserts it into Server.Connection.FileOpenTable with the following default values:

  • A new FID is created to uniquely identify this Open in Server.Connection.FileOpenTable.

  • Server.Open.TreeConnect is set to the TreeConnect on which the open request was performed, and Server.Open.TreeConnect.OpenCount is increased by 1.

The server registers the Open by invoking the event Server Registers a New Open ([MS-SRVS] section 3.1.6.4) and assigns the return value to Server.Open.FileGlobalId.

All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.

<324> Section 3.3.5.55: Windows-based servers request a write to a printer spool file in the object store as described in [MS-FSA] section 2.1.5.4, with the following mapping of input elements:

  • Open is the Open indicated by the SMB_Parameters.Words.FID field of the request.

  • ByteOffset is not used.

  • ByteCount is the SMB_Data.Bytes.DataLength field of the request.

  • InputBuffer is copied from the SMB_Data.Bytes.Data field of the request.

The returned Status is copied into the SMB_Header.Status field of the response. If the write fails, the Status is returned in an Error Response.

<325> Section 3.3.5.56: Windows-based servers flush a file by passing the Open to the algorithm described in [MS-FSA] section 2.1.5.7. The returned Status is copied into the SMB_Header.Status field of the response.

<326> Section 3.3.5.57.2: Windows-based servers set pipe state information on named pipes as described in [MS-FSA] section 2.1.5.15, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request.

  • FileInformationClass is FilePipeInformation (see [MS-FSCC] section 2.4).

  • InputBuffer is a buffer formatted as a FILE_PIPE_INFORMATION structure, specified in [MS-FSCC] section 2.4.36, where the specific values are taken from the Trans_Parameters.PipeState field of the request, according to the following mapping.

    PipeState bit name

    Values

    FilePipeInformation value

     Nonblocking

    0

    FILE_PIPE_QUEUE_OPERATION

    1

    FILE_PIPE_COMPLETE_OPERATION

    ReadMode

    0

    FILE_PIPE_BYTE_STREAM_MODE

    1

    FILE_PIPE_MESSAGE_MODE

  • InputBufferSize is 8 bytes, the size of the FILE_PIPE_INFORMATION data.

The returned Status is copied into the SMB_Header.Status field of the response.

<327> Section 3.3.5.57.3: Windows NT Server does not support this transaction subcommand. It returns a Status of STATUS_INVALID_PARAMETER (ERRDOS/ERRinvalidparam).

<328> Section 3.3.5.57.4: Windows-based servers perform two queries for information on the underlying object store, each with different information levels, as  described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request and is used for both queries.

  • FileInformationClass is FilePipeInformation ([MS-FSCC] section 2.3.47) for one query and FilePipeLocalInformation ([MS-FSCC] section 2.3.48) for the other.

  • OutputBufferSize is 8 bytes for the FilePipeInformation buffer (size of FILE_PIPE_INFORMATION data), and 40 bytes for the FilePipeLocalInformation buffer (size of FILE_PIPE_LOCAL_INFORMATION data).

If either query returns an error status in Status, that value is set as the SMB_Header.Status field of the response message. If both return success, a success status is used, and the following additional mapping of output elements applies:

  • OutputBuffer: The output buffers from both queries are used to construct an SMB_NMPIPE_STATUS data type, as specified in section 2.2.1.3. The SMB_NMPIPE_STATUS buffer is the Trans_Parameters.NMPipeState field of the response.

  • ByteCount is not used.

<329> Section 3.3.5.57.5: Windows-based servers perform a query for state information of a named pipe on the underlying object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request.

  • FileInformationClass is FilePipeLocalInformation ([MS-FSCC] section 2.4.37).

  • OutputBufferSize is 40 bytes, the size of the FILE_PIPE_LOCAL_INFORMATION data.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is used to populate the Trans_Data subfields of the response, according to the following mapping.

    FilePipeLocalInformation field

    Response Trans_Data subfield

    OutboundQuota

    OutputBufferSize

    InboundQuota

    InputBufferSize

    MaximumInstances

    MaximumInstances

    CurrentInstances

    CurrentInstances

  • ByteCount is not used.

<330> Section 3.3.5.57.6: Windows-based servers peek at named pipes on the underlying object store using an FSCTL_PIPE_PEEK request ([MS-FSCC] section 2.3.46). Processing follows as described in [MS-FSA] section 2.1.5.10, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request.

  • OutputBufferSize is 16 bytes (size of FSCTL_PIPE_PEEK reply data) + SMB_Parameters.Words.MaxDataCount bytes.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is an FSCTL_PIPE_PEEK reply structure ([MS-FSCC] section 2.3.46) and is used to populate the Trans_Parameters and Trans_Data blocks of the response. The following fields from the OutputBuffer map to subfields in the response. Note that FSCTL_PIPE_PEEK.MessageLength is not mapped directly, but is used as part of a calculation.

    FSCTL_PIPE_PEEK reply field

    SMB response field

    NamedPipeState

    Trans_Parameters.NamedPipeState

    ReadDataAvailable

    Trans_Parameters.ReadDataAvailable

    NumberOfMessages

    Not used

    MessageLength

    Trans_Parameters.MessageBytesLength = MessageLength –SMB_Parameters.Words.DataCount

    Data

    Trans_Data.ReadData

<331> Section 3.3.5.57.7: Windows-based servers write data to and read data from ("transceive" on) named pipes on the underlying object store using an FSCTL_PIPE_TRANSCEIVE request ([MS-FSCC] section 2.3.47). Processing follows as described in [MS-FSA] section 2.1.5.10, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request.

  • InputBufferSize  is SMB_Parameters.Words.TotalDataCount bytes.

  • InputBuffer is the Trans_Data.WriteData field of the request.

  • OutputBufferSize is 4 bytes (size of FSCTL_PIPE_TRANSCEIVE reply data) + SMB_Parameters.Words.MaxDataCount bytes.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • OutputBuffer is an FSCTL_PIPE_TRANSCEIVE structure ([MS-FSCC] section 2.3.48) and is copied into the ReadData field of the response.

<332> Section 3.3.5.57.8: Windows NT servers allow only message mode for raw writes on named pipes. If the ReadMode bitmask of the PipeState field for the named pipe is set to byte mode, the server fails raw write requests on named pipes and returns STATUS_INVALID_PARAMETER.

<333> Section 3.3.5.57.8: Windows NT Server permits only a 2-byte write that contains two null (0x00) padding bytes, and requires that the pipe is in message mode. If these conditions are not met, NT server returns a STATUS_INVALID_PARAMETER error.

<334> Section 3.3.5.57.9: Windows-based servers read data from named pipes on the underlying object store as described in [MS-FSA] section 2.1.5.3, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request.

  • ByteCount is SMB_Parameters.Words.MaxDataCount bytes.

  • ByteOffset is zero.

  • IsNonCached is not used.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

<335> Section 3.3.5.57.10: Windows-based servers write data to named pipes on the underlying object store as described in [MS-FSA] section 2.1.5.4, with the following mapping of input elements:

  • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request.

  • ByteSize is SMB_Parameters.Words.TotalDataCount bytes.

  • InputBuffer is the Trans_Data.WriteData field of the request.

  • ByteOffset is zero.

  • IsWriteThrough and IsNonCached are not used.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the following additional mapping of output elements applies:

  • BytesWritten is copied into the Trans_Parameters.BytesWritten field of the response

<336> Section 3.3.5.57.11: Windows-based servers test the availability of named pipes on the underlying object store using an FSCTL_PIPE_WAIT request ([MS-FSCC] section 2.3.49). Processing follows as described in [MS-FSA] section 2.1.5.10, with the following mapping of input elements:

  • InputBufferSize is 14 + SMB_Data.ByteCount bytes (the size of the FSCTL_PIPE_WAIT request structure's static portion plus the size of the variable-length pipe name).

  • InputBuffer is the FSCTL_PIPE_WAIT request structure.

The returned Status is copied into the SMB_Header.Status field of the response.

<337> Section 3.3.5.57.11: Windows NT Server honors the Timeout field for this transaction.

<338> Section 3.3.5.58.1: Windows-based servers pass information level requests to the underlying object store using the information level's corresponding information class. Each information level's corresponding mapping to one or more information classes is given in the information level's corresponding subsection of section 2.2.8. Information classes are defined in [MS-FSCC] sections 2.4 and 2.5, and their corresponding behaviors are described in [MS-FSA] sections 2.1.5.12 and 2.1.5.13, with the following additional considerations:

  • The Open input element required for each information class's processing algorithm is either the Server.Open that matches the FID of the request or created by opening the file indicated by the pathname in the request. If the open operation fails, the Status is returned in an Error Response, and processing is complete.

  • If the preceding open operation succeeds, once processing completes, the Open is closed.

<339> Section 3.3.5.58.2: Windows-based servers open files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

  • PathName is the Trans2_Parameters.FileName field from the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set as follows:

    • The AccessMode subfield of the Trans2_Parameters.AccessMode field in the request is used to set the value of DesiredAccess. The AccessMode subfield represents the lowest order 4 bits of the AccessMode field (0x0007), as shown in the table in section 2.2.4.3.1. The mapping of values is as follows.

    AccessMode.AccessMode

    DesiredAccess

    0

    GENERIC_READ 0x80000000

    1

    GENERIC_WRITE | FILE_READ_ATTRIBUTES0x40000000 | 0x00000080

    2

    GENERIC_READ | GENERIC_WRITE 0x80000000 | 0x40000000

    3

    GENERIC_READ | GENERIC_EXECUTE 0x80000000 | 0x20000000

    • For any other value of AccessMode.AccessMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).

  • ShareAccess is set as follows:

    • The SharingMode subfield of the Trans2_Parameters.AccessMode field in the request is used to set the value of ShareAccess. The SharingMode subfield is a 4-bit subfield of the AccessMode field (0x0070), as shown in the table in section 2.2.4.3.1. The mapping of values is as follows.

    AccessMode.SharingMode

    ShareAccess

    0

    Compatibility mode (see following)

    1

    0x0L (don't share, exclusive use)

    2

    FILE_SHARE_READ

    3

    FILE_SHARE_WRITE

    4

    FILE_SHARE_READ | FILE_SHARE_WRITE

    • For Compatibility mode, special filename suffixes (after the "." in the filename) are mapped to SharingMode 4. The special filename suffix set is: "EXE", "DLL", "SYM", "COM". All other file names are mapped to SharingMode 3.

    • If AccessMode field in the request is 0xFF, and the file is already open on the server, the current sharing mode of the existing Open is preserved, and a FID for the file is returned. If the file is not already open on the server, the server attempts to open the file using SharingMode 1.

    • For any other value of AccessMode.SharingMode, this algorithm returns STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess).

  • CreateOptions bits are set as follows.

    CreateOptions value

    TRNS2_OPEN2 equivalent

    FILE_WRITE_THROUGH

    AccessMode.WritethroughMode == 1

    FILE_SEQUENTIAL_ONLY

    AccessMode.ReferenceLocality == 1

    FILE_RANDOM_ACCESS

    AccessMode.ReferenceLocality == 2 or

    AccessMode.ReferenceLocality == 3

    FILE_ WRITE_THROUGH

    AccessMode.CacheMode == 1

    FILE_NON_DIRECTORY_FILE

    Is set

    FILE_COMPLETE_IF_OPLOCKED

    Is set

    FILE_NO_EA_KNOWLEDGE

    SMB_Header.Flags2 & SMB_FLAGS2_KNOWS_EAS == 0

    • All other bits are unused.

  • CreateDisposition is set as follows:

    CreateDisposition Value

    Trans2_Parameters.OpenMode Equivalent

    Invalid combination; return STATUS_OS2_INVALID_ACCESS (ERRDOS/ERRbadaccess)

    FileExistsOpts = 0 & CreateFile = 0

    FILE_CREATE

    FileExistsOpts = 0 & CreateFile = 1

    FILE_OPEN

    FileExistsOpts = 1 & CreateFile = 0

    FILE_OPEN_IF

    FileExistsOpts = 1 & CreateFile = 1

    FILE_OVERWRITE

    FileExistsOpts = 2 & CreateFile = 0

    FILE_OVERWRITE_IF

    FileExistsOpts = 2 & CreateFile = 1

  • DesiredFileAttributes is set as follows:

    • DesiredFileAttributes is set to the bitwise AND of the FileAttributes field in the request and

      ( SMB_FILE_ATTRIBUTE_READONLY |

        SMB_FILE_ATTRIBUTE_HIDDEN   |

        SMB_FILE_ATTRIBUTE_SYSTEM   |

        SMB_FILE_ATTRIBUTE_ARCHIVE  |

        SMB_FILE_ATTRIBUTE_DIRECTORY ).

    • If the resulting value of DesiredFileAttributes is zero, DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL. See sections 2.2.1.2.3 and 2.2.1.2.4.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request; otherwise, IsCaseSensitive is set depending upon system defaults. For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response and processing is complete.

If the operation is successful, processing continues as follows:

  • If the request's Trans2_Data.ExtendedAttributesList is nonzero, Windows-based servers set the extended attribute information on the object store as described in [MS-FSA] section 2.1.5.15, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileFullEaInformation.

    • InputBuffer is the Trans2_Data.ExtendedAttributeList field of the request.

    • InputBufferSize is the SMB_Parameters.Words.TotalDataCount field of the request.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the operation is successful, processing continues as follows:

  • If the REQ_OPLOCK flag is set in the Trans2_Parameters.Flags field of the request, an OpLock is being requested. Windows-based servers obtain OpLocks as described in [MS-FSA] section 2.1.5.18, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operation.

    • Type is LEVEL_BATCH if both the REQ_OPLOCK flag and the REQ_OPLOCK_BATCH flag are set, or LEVEL_ONE if only the REQ_OPLOCK flag is set.

      If an OpLock is granted, the Trans2_Parameters.OpenResults.LockStatus bit of the response is set.

  • The Trans2_Parameters.AccessMode from the request is copied to the response.

  • Open.File.FileType is used to set the Trans2_Parameters.ResourceType.

  • Windows-based servers obtain the Trans2_Parameters.FileAttributes response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileBasicInformation.

      If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • SMB_Parameters.Words.FileAttrs is set to OutputBuffer.FileAttributes.

  • If the REQ_ATTRIB flag is set in the Trans2_Parameters.Flags field of the request, Windows-based servers obtain the Trans2_Parameters.FileDataSize response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileStandardInformation.

      If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • Trans2_Parameters.FileDataSize is set to the lowest-order 32 bits of OutputBuffer.EndOfFile.

  • If the REQ_EASIZE flag is set in the Trans2_Parameters.Flags field of the request, Windows-based servers obtain the Trans2_Parameters.ExtendedAttributeLength response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileEaInformation.

      If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • Trans2_Parameters.ExtendedAttributeLength is set to OutputBuffer.EaSize.

      If the query fails, the Status is returned in an Error Response, and processing is complete.

  • A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.

<340> Section 3.3.5.58.3: If no matching entries are found, Windows NT servers fail the TRANS2_FIND_FIRST2 Request (section 2.2.6.2.1) and return a full TRANS2_FIND_FIRST2 Response (section 2.2.6.2.2), setting all the fields to zero.

<341> Section 3.3.5.58.3: Windows-based servers close the search and return a nonzero SID field value.

<342> Section 3.3.5.58.3: Windows-based servers process this command in the same way as the SMB_COM_SEARCH (section 2.2.4.58) and SMB_COM_FIND (section 2.2.4.59) commands (see the notes in section 3.3.5.47), with the following differences:

  • The FileInformationClass is set to FileDirectoryInformation, FileBothDirectoryInformation, or FileFullDirectoryInformation, depending upon the information required in the EA to be returned.

  • The FileIndex field is not used.

  • Trans2_Parameters.SearchCount replaces SMB_Parameters.Words.MaxCount.

  • The files returned are not required to have short names.

  • Instead of returning an SMB_Directory_Information structure for each directory entry that matches the required FileName and SearchAttributes fields, the server returns an InformationClass structure of the type requested in the Trans2_Parameters.InformationLevel field. If the requested InformationLevel is SMB_INFO_QUERY_EAS_FROM_LIST (section 2.2.8.1.3), the server queries the file for the list of extended attributes (EAs), as described in [MS-FSA] section 2.1.5.12. FileInformationClass is set to FileFullEaInformation. For each AttributeName field listed in the GetExtendedAttributeList field, the corresponding FILE_FULL_EA_INFORMATION data returned from the query is converted into SMB_FEA (section 2.2.1.2.2) format and copied into the Trans2_Data block of the response. If an error is returned, the Status is not copied into the SMB_Header.Status field.  Instead, the offset of the GetExtendedAttributeList.GEAList field entry that caused the error is stored in the EaErrorOffset field, and no more EAs are returned.

<343> Section 3.3.5.58.4: Windows-based servers process this command in the same way as the TRANS2_FIND_FIRST2 (section 2.2.6.2) except that the FileIndex field is used to restart the search at the selected location.

<344> Section 3.3.5.58.6: If the InformationLevel field is SMB_QUERY_FILE_NAME_INFO, Windows-based servers set the Trans2_Data.FileName field in response to the Server.Open.PathName ADM element where the Server.Open.FID ADM element matches the FID field in the request. If the InformationLevel field is SMB_QUERY_FILE_ALL_INFO, Windows-based servers set the Trans2_Data.FileName field in the response to the full pathname relative to the root of the share.

<345> Section 3.3.5.58.8: If the InformationLevel field is SMB_QUERY_FILE_NAME_INFO, Windows-based servers set the Trans2_Data.FileName field in response to the Server.Open.PathName ADM element where the Server.Open.FID ADM element matches the FID field in the request. If the InformationLevel field is SMB_QUERY_FILE_ALL_INFO, Windows-based servers set the Trans2_Data.FileName field in the response to the full pathname relative to the root of the share.

<346> Section 3.3.5.58.10: Windows-based servers create directories within the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

  • PathName is the Trans2_Parameters.DirectoryName field from the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is set to FILE_TRAVERSE (which has the same value as FILE_EXECUTE: 0x00000020).

  • ShareAccess is set to 0x00000000.

  • CreateOptions is set to FILE_DIRECTORY_FILE.

  • CreateDisposition is set to FILE_CREATE.

  • DesiredFileAttributes is set to FILE_ATTRIBUTE_NORMAL.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header. Flags field of the request.  Otherwise, IsCaseSensitive is set depending upon system defaults.  For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.

  • If the request's Trans2_Data.ExtendedAttributesList is nonzero, Windows-based servers set the extended attribute (EA) information on the object store as described in [MS-FSA] section 2.1.5.15, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileFullEaInformation.

    • InputBuffer is the Trans2_Data.ExtendedAttributeList field of the request.

    • InputBufferSize is the SMB_Parameters.Words.TotalDataCount field of the request.

The returned Status is copied into the SMB_Header.Status field of the response. If the operation is successful, the Open returned from the process described in [MS-FSA] section 2.1.5.1 is closed. All other results are ignored.

<347> Section 3.3.5.59.1: This is dependent upon the underlying file system. On Windows NT Server, if the request to create a file is performed on a Windows FAT or FAT32 file system, the request fails with STATUS_ACCESS_DENIED. Otherwise, it fails with STATUS_PRIVILEGE_NOT_ HELD.

<348> Section 3.3.5.59.1: Windows-based servers open files in the object store as described in [MS-FSA] section 2.1.5.1, with the following mapping of input elements:

  • RootOpen is provided in one of two ways:

    • If NT_Trans_Parameters.RootDirectoryFID is zero, RootOpen is provided by using the SMB_Header.TID to find the matching Server.TreeConnect in the Server.Connection.TreeConnectTable. The server then acquires an Open on Server.TreeConnect.Share.LocalPath, which is passed as RootOpen.

    • If NT_Trans_Parameters.RootDirectoryFID is nonzero, RootOpen is provided by looking up the RootDirectoryFID in the Server.Connection.FileOpenTable.

  • PathName is the NT_Trans_Parameters.FileName field of the request.

  • SecurityContext is found by using the SMB_Header.UID to look up the matching Session entry in the Server.Connection.SessionTable. The Server.Session.UserSecurityContext is passed as SecurityContext.

  • DesiredAccess is the NT_Trans_Parameters.DesiredAccess field of the request. The FILE_READ_ATTRIBUTES attribute is added (using a bitwise OR) to ensure that the server can query attributes once the file has been opened.

  • ShareAccess is the NT_Trans_Parameters.ShareAccess field of the request.

  • CreateOptions is the NT_Trans_Parameters.CreateOptions field of the request. The FILE_COMPLETE_IF_OPLOCKED option is added (using a bitwise OR) to the set provided by the client.  If the FILE_NO_INTERMEDIATE_BUFFERING flag is set, it is cleared, and FILE_WRITE_THROUGH is set.

  • CreateDisposition is the NT_Trans_Parameters.CreateDisposition field of the request.

  • DesiredFileAttributes is the NT_Trans_Parameters.ExtFileAttributes field of the request.

  • IsCaseSensitive is set to FALSE if the SMB_FLAGS_CASE_INSENSITIVE bit is set in the SMB_Header.Flags field of the request; otherwise, IsCaseSensitive is set depending upon system defaults.  For more information, see the description of the OBJ_CASE_INSENSITIVE flag of the OBJECT_ATTRIBUTES structure [MSDOCS-OBJ_ATTRIBS].

  • OpLockKey is empty.

Windows-based servers complete the NT_TRANSACT_CREATE Request (section 2.2.7.1.1) by calling the Win32 IoCreateFile() function, which allows both security descriptors (SDs) and extended attributes (EAs) to be set directly rather than having to set them in separate steps. See [MSDN-IoCreateFile]. With respect to the algorithm presented in [MS-FSA] section 2.1.5.1:

  • If the request's NT_Trans_Parameters.SecurityDescriptorLength value is greater than zero, Windows-based servers set Open.File.SecurityDescriptor to the security descriptor passed in the NT_Trans_Data.SecurityDescriptor field in the request. (The SD is passed to the object store in the ObjectAttributes parameter of IoCreateFile().)

  • If the request's NT_Trans_Parameters.EALength value is greater than zero, Windows-based servers set Open.File.ExtendedAttributes and Open.File.ExtendedAttributesLength from NT_Trans_Data.ExtendedAttributes and NT_Trans_Parameters.EALength, respectively. (These values are passed to the object store via the EaBuffer and EaLength parameters of IoCreateFile().)

The returned Status is copied into the SMB_Header.Status field of the response. If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the operation is successful, processing continues as follows:

  • If either the NT_CREATE_REQUEST_OPLOCK or NT_CREATE_REQUEST_OPBATCH flag is set in the SMB_Parameters.Words.Flags field of the request, an OpLock is being requested. Windows-based servers obtain OpLocks as described in [MS-FSA] section 2.1.5.18, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operation.

    • Type is LEVEL_BATCH if the NT_CREATE_REQUEST_OPBATCH flag is set, or LEVEL_ONE if the NT_CREATE_REQUEST_OPLOCK flag is set.

  • If an OpLock is granted, the SMB_Parameters.Words.OpLockLevel field of the response is set.

The returned Status is copied into the SMB_Header.Status field of the response.  If the operation fails, the Status is returned in an Error Response, and processing is complete.

If the operation is successful, processing continues as follows:

  • Windows-based servers obtain the extended file attribute and timestamp response information by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileBasicInformation.

  • If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • NT_Trans_Parameters.ExtFileAttributes is set to OutputBuffer.FileAttributes.

    • NT_Trans_Parameters.CreateTime is set to OutputBuffer.CreateTime.

    • NT_Trans_Parameters.LastAccessTime is set to OutputBuffer.LastAccessTime.

    • NT_Trans_Parameters.LastWriteTime is set to OutputBuffer.LastWriteTime.

    • NT_Trans_Parameters.LastChangeTime is set to OutputBuffer.ChangeTime.

  • Windows-based servers obtain the file size response field values by querying file information from the object store as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Open passed through from the preceding operations.

    • FileInformationClass is FileStandardInformation.

  • If the query fails, the Status is returned in an Error Response, and processing is complete. Otherwise:

    • NT_Trans_Parameters.AllocationSize is set to OutputBuffer.AllocationSize.

    • NT_Trans_Parameters.EndOfFile is set to OutputBuffer.EndOfFile.

  • If the query fails, the Status is returned in an Error Response, and processing is complete.

  • Open.File.FileType is used to set the NT_Trans_Parameters.ResourceType and NT_Trans_Parameters.Directory fields of the response.

  • If Open.File.FileType indicates a named pipe, Windows-based servers perform two queries for named pipe state on the underlying object store, each with different information levels, as described in [MS-FSA] section 2.1.5.12, with the following mapping of input elements:

    • Open is the Server.Open identified by the SMB_Parameters.Words.Setup.FID field of the request and is used for both queries.

    • FileInformationClass is FilePipeInformation for one query and FilePipeLocalInformation for the other ([MS-FSCC] section 2.4).

    • OutputBufferSize is 8 bytes for the FilePipeInformation buffer (size of FILE_PIPE_INFORMATION data), and 40 bytes for the FilePipeLocalInformation buffer (size of FILE_PIPE_LOCAL_INFORMATION data).

  • If either query returns an error status in Status, that value is set as the SMB_Header.Status field of the response message. If both return success, a success status is used, and the following additional mapping of output elements applies:

    • OutputBuffer: The output buffers from both queries are used to construct an SMB_NMPIPE_STATUS (section 2.2.1.3) data type. The SMB_NMPIPE_STATUS buffer is copied into the NT_Trans_Parameters.NMPipeState field of the response.

    • ByteCount is not used.

  • A new FID is generated for the Open returned. All of the other results of the Open operation are ignored. The FID is copied into the SMB_Parameters.Words.FID field of the response.

<349> Section 3.3.5.59.2: Windows-based servers send IOCTL and FSCTL requests to the underlying object store as described in each control code's specific subsection of [MS-FSA] section 2.1.5.10.

<350> Section 3.3.5.59.3: Windows-based servers set security descriptors on objects within the object store as described in [MS-FSA] section 2.1.5.17, with the following mapping of input elements:

  • Open is the Open indicated by looking up FID in Server.Connection.FileOpenTable.

  • SecurityInformation is copied from the NT_Trans_Parameters.SecurityInformation field in the request.

  • InputBuffer is copied from the NT_Trans.Data_SecurityDescriptor field in the request.

Upon completion, the returned Status is copied into the SMB_Header.Status field of the response message.

<351> Section 3.3.5.59.4: Windows-based servers provide notification of changes within the object store as described in [MS-FSA] section 2.1.5.11, with the following mapping of input elements:

  • Open is the Open indicated by looking up FID in Server.Connection.FileOpenTable.

  • WatchTree is set based upon the value of the WatchTree field in the request.

  • CompletionFilter is copied from the CompletionFilter field in the request.

A thread of execution on the server waits for the completion of the notification request.  The notification request is an object store I/O operation, and can be canceled as described in sections 2.2.4.65 and 3.3.5.52, and in [MS-FSA] section 2.1.5.20.

Upon completion, the returned Status is copied into the SMB_Header.Status field of the response message.  If the operation is successful, the NotifyEventEntries are copied from the OutputBuffer to the NT_Trans_Parameters.FileNotifyInformation field.

<352> Section 3.3.5.59.5: Windows-based servers query security descriptors on objects within the object store as described in [MS-FSA] section 2.1.5.14, with the following mapping of input elements:

  • Open is the Open indicated by looking up FID in Server.Connection.FileOpenTable.

<353> Section 3.3.6.4: Windows-based servers use a default timeout value of 2 minutes. Windows-based servers close the connections if Server.Connection.SelectedDialect is empty and current time minus Server.Connection.CreationTime is more than 30 seconds.

<354> Section 3.3.7.1: Windows TDI transport drivers indicate transport disconnection by signaling an Error Notification as described in [MSDN-RecErrorNotif].

<355> Section 3.3.7.2: Windows SMB servers request that a TDI transport driver close a connection by issuing a disconnect request, as described in [MSDN-DiscntEndpoint], and by subsequently closing the TDI file object.

<356> Section 3.3.7.3: Windows SMB servers request that TDI transport drivers accept or reject incoming connections as described in [MSDN-MakeEndpoint].

<357> Section 3.4.4.9: Windows-based SMB clients on Windows NT 4.0 operating system Service Pack 2 (SP2), Windows 2000, and Windows Server 2003 do not check the CAP_DFS flag and always send the DFS referral request to the server.

<358> Section 5.1: Windows NT servers provide a mechanism for restricting the access of anonymous logon users (also known as null session connections). See [KB143474] for a description.

Guest account support is optional and can be disabled.

<359> Section 5.1: Share level access control is deprecated in favor of user level access control.

Windows clients can be configured to fail authentication if plaintext passwords are required by the server. By default, Windows 98 clients require that the server accept challenge/response authentication. By default, Windows NT 4.0 and Windows NT 4.0 SP2 Workstation clients send plaintext passwords if requested by the server. Windows NT 4.0 SP3 clients require challenge/response by default. See [MSDN-ENPLAINTXT].