Major Description
After the reimplementation of the SlingPostServlet, the content creation and modification operation (the default if the :operation parameter is not set) executes in the following order:
- Ensure addressed content exists, creating if needed
- Handle all @Delete parameters
- Handle all @MoveFrom parameters
- Handle all @CopyFrom parameters
- Handle ordinary content setting
- Handle node ordering indicated by the :order parameter
The old SlingPostServlet first did the moves and copies and only then did the deletes. The problem with the new ordering lies exactly in the @MoveFrom and @CopyFrom support: This functionality has been implemented to support moving (or copying) content uploaded asynchronously, e.g. with a Flash file upload.
Now if the Flash upload created a temporary folder, it should of course be possible to remove it after moving/copying the uploaded files. With executing the @Delete before @MoveFrom and @CopyFrom disables this because the folder may already have been removed when the contents should moved or copied.
The fix for this is to move @Delete handling after @MoveFrom and @CopyFrom. This does not harm normal parameter handling but enables this temporary folder removal.
As a secondary effect of this change we have to slightly change the @MoveFrom and @CopyFrom operation. Now, if for a property "prop" both a "prop@Delete" and "prop@MoveFrom" parameter is set, the property is removed before the source is being moved over. If we handle @Delete after moving, this could of course cause the immediate removal of the data just copied or moved.
Thus, the @MoveFrom and @CopyFrom handling is modified to disable @Delete handling if the move or copy was successfull. If move or copy were not successull, because the source did not exist, the @Delete operation is still executed.