none
[MS-OXCFXICS] FastTransfer "move" RRS feed

  • Question

  • [This is similar to previous questions on fast transfer]

    [MS-OXCFXICS] v20100729 Section 2.2.3.1.1.3.1 "CopyFlags" contains this table row:

    Move 0x01 MUST NOT be passed if InputServerObject is not a folder. If this flag is set, the client identifies the FastTransfer operation being configured as a logical part of a larger object move operation. If this flag is not set, the client is not identifying the FastTransfer operation being configured as a logical part of a larger object move operation.

    Section 2.2.3.1.2.1.2 "CopyFlags" contains similar wording.

    Question 1. For a source (download) operation, I am assuming that setting this flag results in the source object (or object property, object hierachy or flags, as appropriate) being (soft?) deleted at the successful completion of the transfer. Is this the case?

    Question 2. What does this mean for an upload or server->client->server operation (i.e. what does the target server do with this flag in RopFastTransferDestinationConfigure)?

    Comment 1. In Section 2.2.3.1.1.3.1, the requirement that "MUST NOT be passed if InputServerObject is not a folder" doesn't appear necessary given the earlier requirement that the InputServerObject MUST be a folder.

    Comment 2. In Product Behavior Note <7>, it would be useful to describe what that "configured as part of a larger object move operation" behaviour results in terms of server deletes / operations (at least for the visible behaviour).

    Brad

    Thursday, October 7, 2010 2:50 AM

Answers

  • Hi Brad,

     

    I have the answers to these questions.

     

    Question 1. For a source (download) operation, I am assuming that setting this flag results in the source object (or object property, object hierachy or flags, as appropriate) being (soft?) deleted at the successful completion of the transfer. Is this the case?

     

    Answer:

    The FastTransfer (FX) operation does NOT do any deletions from the source.  It is up to the client to perform the deletions after each item is transferred to the client via FX.  It is up to the client to determine which items to go back to the server to delete.  “Move” means “don’t give me anything I cannot delete later”. 

     

    Question 2. What does this mean for an upload or server->client->server operation (i.e. what does the target server do with this flag in RopFastTransferDestinationConfigure)?

     

    Answer:

    Exchange 2010 does not do anything with this flag on RopFastTransferDestinationConfigure.  However, Exchange 2007 and Exchange 2003 both use this flag to determine whether or not the “Non-Read Notification” pending flag needs to be cleared if used for CopyFolder or CopyMessages.  If the flag is NOT passed, the “Non-Read Notification” pending flag is cleared on each message saved to destination.  If flag IS passed, the “Non-Read Notification” pending flag is left alone.

     

    Comments 1 & 2 are being considered for a future release of the document.

     

    Comment 2. In Product Behavior Note <7>, it would be useful to describe what that "configured as part of a larger object move operation" behaviour results in terms of server deletes / operations (at least for the visible behaviour).

     

    More details on Comment 2, as it relates to Question 1:

    The flag is used as described.  It is just telling the source server that the FX is part of a larger Move operation.  Even in a server-to-client-to-server scenario it is up to the client to delete the items from the source.  How the client determines which items to delete is implementation details.  Our client has to parse the FX stream before passing to the destination server.  It should be made clear that using the Move flag on the source does NOT trigger deletes automatically.

     

     

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    • Marked as answer by Brad Hards Thursday, November 4, 2010 11:52 PM
    Thursday, November 4, 2010 5:04 PM

All replies

  • Hi Brad - thanks for your post. One of my team colleagues will be in touch with you soon. Thanks for your patience!

    Regards,
    Bill Wesse, US-CSS DSC Protocol Team

    Thursday, October 7, 2010 10:08 AM
  • Hi Brad,

    I will investigate this and follow up with you.

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

     

    Friday, October 8, 2010 5:43 PM
  • Hi Brad,

    As we discussed on Tuesday, I'm still investigating this and will update you soon.

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Thursday, October 28, 2010 5:15 PM
  • Hi Brad,

     

    I have the answers to these questions.

     

    Question 1. For a source (download) operation, I am assuming that setting this flag results in the source object (or object property, object hierachy or flags, as appropriate) being (soft?) deleted at the successful completion of the transfer. Is this the case?

     

    Answer:

    The FastTransfer (FX) operation does NOT do any deletions from the source.  It is up to the client to perform the deletions after each item is transferred to the client via FX.  It is up to the client to determine which items to go back to the server to delete.  “Move” means “don’t give me anything I cannot delete later”. 

     

    Question 2. What does this mean for an upload or server->client->server operation (i.e. what does the target server do with this flag in RopFastTransferDestinationConfigure)?

     

    Answer:

    Exchange 2010 does not do anything with this flag on RopFastTransferDestinationConfigure.  However, Exchange 2007 and Exchange 2003 both use this flag to determine whether or not the “Non-Read Notification” pending flag needs to be cleared if used for CopyFolder or CopyMessages.  If the flag is NOT passed, the “Non-Read Notification” pending flag is cleared on each message saved to destination.  If flag IS passed, the “Non-Read Notification” pending flag is left alone.

     

    Comments 1 & 2 are being considered for a future release of the document.

     

    Comment 2. In Product Behavior Note <7>, it would be useful to describe what that "configured as part of a larger object move operation" behaviour results in terms of server deletes / operations (at least for the visible behaviour).

     

    More details on Comment 2, as it relates to Question 1:

    The flag is used as described.  It is just telling the source server that the FX is part of a larger Move operation.  Even in a server-to-client-to-server scenario it is up to the client to delete the items from the source.  How the client determines which items to delete is implementation details.  Our client has to parse the FX stream before passing to the destination server.  It should be made clear that using the Move flag on the source does NOT trigger deletes automatically.

     

     

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    • Marked as answer by Brad Hards Thursday, November 4, 2010 11:52 PM
    Thursday, November 4, 2010 5:04 PM
  • Mark,

    Thanks for this information - much appreciated as always.

    Brad

     

    Thursday, November 4, 2010 11:52 PM