3.2.5.8 Processing RopCopyTo
When the server receives a RopCopyTo ROP request buffer ([MS-OXCROPS] section 2.2.8.12) from the client, the server parses the buffer. The server responds with a RopCopyTo ROP response buffer. For details about how the server parses buffers and processes ROPs, see [MS-OXCROPS] section 3.2.5.1. For details about how the server formats buffers for the response, see [MS-OXCROPS] section 3.2.5.2.
The server MUST copy or move only the writable properties that are not specified in the ExcludedTags field.
If the Move flag is set in the CopyFlags field of the ROP request buffer, the server MAY<8> delete the copied properties from the source object. If the NoOverwrite flag is set in the CopyFlags field, the server MUST NOT overwrite any properties that already have a value on the destination object. If any other bits are set in the CopyFlags field, the server SHOULD<9> return an InvalidParameter error (0x80070057).
In the case of Message objects, the changes on either source or destination MUST NOT be persisted until the RopSaveChangesMessage ROP ([MS-OXCROPS] section 2.2.6.3) is successfully issued. In the case of Attachment objects, the changes on either source or destination MUST NOT be persisted until the RopSaveChangesAttachment ROP ([MS-OXCROPS] section 2.2.6.15) and the RopSaveChangesMessage ROP are successfully issued, in that order.
In the case of Folder objects, the changes on the source and destination MUST be immediately persisted. If the original object is a Folder object and the CopyFlags field has the Move flag set, the server MAY return a NotSupported error (0x80040102). The server SHOULD<10> return a NotSupported error if the RopCopyTo ROP request specifies a public folder as either the source object or the destination object.
If the client requests asynchronous processing, the server can process this ROP asynchronously. During asynchronous processing, the server can indicate that the operation is still being processed by returning a RopProgress ROP response ([MS-OXCROPS] section 2.2.8.13), or it can indicate that the operation has already completed by returning a RopCopyTo ROP response. If the operation fails at any point during the asynchronous processing, the server returns a RopCopyTo ROP response buffer with an appropriate error code. For details about the RopProgress ROP and how it is used, see section 2.2.23 and section 3.2.5.20.
The following error codes SHOULD be returned when the scenarios described in the corresponding Description column of the following table are met.
Error code name |
Value |
Description |
---|---|---|
NotSupported |
0x80040102 |
The source object and destination object are not compatible with each other for the copy operation. The source object and destination object need to be of the same type, and MUST be a Message object, Folder object, or Attachment object. |
MessageCycle |
0x00000504 |
The source message directly or indirectly contains the destination message. |
FolderCycle |
0x8004060B |
The source folder contains the destination folder. |
CollidingNames |
0x80040604 |
A subobject cannot be copied because there is already a subobject existing in the destination object with the same display name, which is specified in the PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5), as the subobject to be copied. |