共用方式為

3.3.5.10 Receiving an SMB_COM_RENAME Request

  • 發行項

Upon receipt of an SMB_COM_RENAME Request (section 2.2.4.8.1), the server MUST enumerate the set of files that matches both the OldFileName pathname and the SearchAttributes field in the request. Each matching file name MUST be renamed according to the format of the NewFileName pathname. If the target name already exists, the Rename operation MUST fail with a Status of STATUS_OBJECT_NAME_COLLISION (ERRDOS/ERRfilexists).<257>

Other considerations:

  • Only a single TID is supplied, so the OldFileName and NewFileName pathnames MUST be within the same share on the server.

  • If SearchAttributes is 0x0000 (SMB_FILE_ATTRIBUTE_NORMAL), the server MUST match only normal files.

  • For each enumerated file, if any of the following attributes are present in file attributes but not specified in SearchAttributes, the rename operation MUST fail with a Status of STATUS_NO_SUCH_FILE (ERRDOS/ERRbadfile). Otherwise, the rename operation MUST include the type or types specified in addition to normal files.

    • SMB_FILE_ATTRIBUTE_HIDDEN

    • SMB_FILE_ATTRIBUTE_SYSTEM

  • This command MUST NOT rename volume labels.

A file to be renamed might currently be open. If it 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 rename MUST fail with STATUS_ACCESS_DENIED (ERRDOS/ERRnoaccess) and Server.Statistics.sts0_permerrors MUST be increased by 1.<258>

  • If another process has the file open, and that process has an OpLock on the file, and the process has asked for extended notification (Batch OpLock), the rename request MUST block until the server has sent an OpLock break request to the owner of the OpLock, as specified in section 3.3.4.2, and either received a response or the OpLock break time-out has expired.<259> The server MUST have the OPLOCK_RELEASE flag set in the TypeOfLock field of the request. The server MUST set the NewOpLockLevel field of the request to 0x00. If the process holding the OpLock closes the file (thus freeing the OpLock) the rename takes place. If not, the rename MUST fail with STATUS_SHARING_VIOLATION.

  • If there is an existing file with the new name, the rename MUST fail with STATUS_OBJECT_NAME_COLLISION. If wildcards are used in a rename operation, and only some of the renames fail for any reason, the request MUST fail silently; that is, an error MUST NOT be returned if at least one of the rename operations was successful.

A server can be processing multiple requests on the same resource concurrently. As a result, there can be interactions between the execution of the Rename operation and other operations such as ongoing searches (SMB_COM_SEARCH, SMB_COM_FIND, TRANS2_FIND_FIRST2, and so on). Although renaming a directory or files 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.

Renaming files using wildcards is supported. Only the final path element of each of the provided pathnames is permitted to contain wildcard characters. Wildcard characters MUST NOT be used in the rest of the path. When wildcard characters are in use, the translation from the old name to the new name proceeds as described in [FSBO].

If a directory is renamed, it MUST NOT have a destination located within itself or any subdirectory within the source directory. The source and destination MUST be at or below the current TID within the file system namespace. If these conditions are not met, the server MUST return STATUS_OBJECT_PATH_SYNTAX_BAD (ERRDOS/ERRbadpath).

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