[
https://issues.apache.org/jira/browse/SLING-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738102#comment-16738102
]
Bertrand Delacretaz commented on SLING-8186:
--------------------------------------------
Don't you think we would have the same name collision problem if we change the
order of operations?
@Delete tries to delete a property but if it doesn't find it it deletes a
Resource with that name under the current parent node if found.
So changing the order of operations would solve your use case but might break
others.
But maybe I'm missing something?
> Moved node is deleted if @Delete parameter points to its name
> -------------------------------------------------------------
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: Servlets Post 2.3.26
> Reporter: Burkhard Pauli
> Assignee: Bertrand Delacretaz
> Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the
> request contains the @Delete parameter at the same time, the file is dropped
> and never saved to the new location.
> Step to reproduce the issue:
> # Create a node of type nt:file at the location {{/content/file}}
> # Execute the following curl command:
> {{curl -u admin:admin -F './test/title=Hello World' -F
> './test/file@MoveFrom=/content/file' -F './test@Delete=true'
> [http://localhost:4502/content]}}
> Observed behaviour:
> The file is not saved at the new location at {{/content/test/file}} and it
> is not available anymore at the old location {{/content/file}}
> Expected:
> The file is saved at the new location {{/content/test/file}} as long as
> other properties are saved when the request contains the delete operation
> (like the title property in the example above).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
