Share via

3.3.5.53 Receiving an SMB_COM_NT_RENAME Request

  • Article

Upon receipt of an SMB_COM_NT_RENAME Request (section 2.2.4.66.1), the server MUST verify that a file exists matching both the OldFileName pathname field and the SearchAttributes field in the request. OldFileName MUST NOT contain wildcard characters; otherwise, the server MUST return an error response with a Status of STATUS_OBJECT_PATH_SYNTAX_BAD (ERRDOS/ERRbadpath).

The processing of the request depends on the information level provided in the InformationLevel field of the request:

  • If the InformationLevel field value is SMB_NT_RENAME_RENAME_FILE (0x0104), the request is treated as if it is an SMB_COM_RENAME Request (section 2.2.4.8.1). Message processing follows as specified in section 3.3.5.10, with the exception that the command code returned in the response SMB Header (section 2.2.3.1) MUST be SMB_COM_NT_RENAME (0xA5).

  • If the InformationLevel field value is neither SMB_NT_RENAME_RENAME_FILE (0x104) nor SMB_NT_RENAME_SET_LINK_INFO (0x103), the server SHOULD fail the request with STATUS_INVALID_SMB (ERRSRV/ERRerror).<319>

  • If the InformationLevel field value is SMB_NT_RENAME_SET_LINK_INFO (0x0103), the original file MUST NOT be renamed. Instead, the server MUST attempt to create a hard link at the target specified in NewFileName. The processing information below applies to receiving a request with an information level of SMB_NT_RENAME_SET_LINK.<320>

If the target name already exists, the hard linking operation MUST fail with STATUS_ACCESS_DENIED(ERRDOS/ERRnoaccess) and Server.Statistics.sts0_permerrors MUST be increased by 1.

Other considerations:

  • Only a single TID is supplied, so the OldFileName and NewFileName pathnames MUST be within the same share on the server. If OldFileName is a directory, NewFileName MUST NOT be a destination located within OldFileName or any of its subdirectories. If these conditions are not met, the server MUST return STATUS_OBJECT_PATH_SYNTAX_BAD (ERRDOS/ERRbadpath).

  • The UID supplied in the request MUST be used to look up the Server.Session.UserSecurityContext of the user.  The user MUST have at least read access to the file for the hard linking operation to succeed. If the user does not have read access to the file, the server MUST return STATUS_ACCESS_DENIED (ERRDOS/ERRnoaccess) and MUST increase Server.Statistics.sts0_permerrors by 1.

  • Only the SMB_FILE_ATTRIBUTE_HIDDEN and SMB_FILE_ATTRIBUTE_SYSTEM attributes are tested against the SearchAttributes field. This command can hard link normal, hidden, and/or system files if the appropriate bits are set in SearchAttributes.

  • This command MUST NOT hard link volume labels.

  • If a file to be renamed is currently open:

    • If the file is opened by the requesting process, it MUST be open in compatibility mode (see section 3.2.4.5.1). If it is not open in compatibility mode, the hard linking MUST fail with STATUS_ACCESS_DENIED (ERRDOS/ERRnoaccess) and Server.Statistics.sts0_permerrors MUST be increased by 1.<321>

    • If another process has the file open, and that process has an opportunistic lock (OpLock) on the file, and the process has asked for extended notification (Batch OpLock), the hard link request MUST block until the server has sent an OpLock break request to the owner of the OpLock and either received a response or the OpLock break time-out has expired. If the process holding the OpLock closes the file (thus freeing the OpLock), the hard linking takes place. If not, the request MUST fail with STATUS_SHARING_VIOLATION (ERRDOS/ERRbadshare).

  • It is possible for a server to be processing multiple requests on the same resource concurrently. As a result, there can be interactions between the execution of the hard link operation and other operations, such as ongoing searches (SMB_COM_SEARCH (section 2.2.4.58), SMB_COM_FIND (section 2.2.4.59), TRANS2_FIND_FIRST2 (section 2.2.6.2), and so on). Although creating a hard link within a directory that is actively being searched is not prohibited, the interaction can disrupt the search, causing it to complete before all directory entries have been returned.<322>

If the operation is successful, the server MUST construct an SMB_COM_NT_RENAME Response (section 2.2.4.66.2) message. The response MUST be sent to the client as specified in section 3.3.4.1.