[MAGNOLIA-288] Copying a page does not copy all binary data properly Created: 09/Feb/05 Updated: 15/Jun/05 Resolved: 15/Jun/05 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 2.01 |
| Fix Version/s: | 2.1 Final |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Andreas Weder | Assignee: | Sameer Charles |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
any |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
If you copy a page containing uploaded binary content (such as images or files), the page is indeed copied, but the binary content is not. As a result, the copy references the same images and files as the original. If you delete either of them, the binary content is gone on all pages referencing them. |
| Comments |
| Comment by Andreas Weder [ 09/Feb/05 ] |
|
Sameer has already implemented a fix on the trunk and the 2.02 branch. It does work most of the time, but still behaves problematic sometimes (i'm looking at the 2.02 branch here):
|
| Comment by Andreas Weder [ 10/Feb/05 ] |
|
I've noted another problem with the current copy routine:
|
| Comment by Sameer Charles [ 11/Feb/05 ] |
|
fixed for 2.0.2 maintenance branch |
| Comment by Andreas Weder [ 12/Feb/05 ] |
|
Thanks, Sameer. I've tested both issues, your fixes work. |
| Comment by Andreas Weder [ 15/Feb/05 ] |
|
We still have a serious bug in the current implementation: if you copy a page upon itself, the copy operation continues endlessly and consumes a lot of resources. Moreover, as long as the copy operation is running, I can see many nodes within nodes carrying the same name. One I close the browser, but login again, the nodes are all gone except for the first copy. That's at least what it looks like. |
| Comment by Markus Zingg [ 28/Feb/05 ] |
|
As it seems the HierarchyManager.copyTo function has changed its semantics. Code that worked before : With the recent fix this does not work anymore. The destination directory is not correctly named (its name is 'empty' like the source node). |
| Comment by Michael Aemisegger [ 22/Mar/05 ] |
|
This is the HierarchyManager.copyTo() method that works for me in all cases (R2.02): public void copyTo(String source, String destination) else { if (destination.startsWith("/")) { destination = destination.replaceFirst("/",""); } if (this.isContentNode(source)) { ContentNode cn = this.addContentNode(this.getContentNode(source), this.getContent(destination)); else { catch (PathNotFoundException notFound) { log.warn("Destination of copyTo operation does not exist. Creating it : " + destination); destinationNode = new Content(this.startPage, destination, true); } this.deepCopy(this.getContent(source), destinationNode); |
| Comment by Michael Aemisegger [ 22/Mar/05 ] |
|
Forget about my last post. That was a fast shoot. It can be done easiear. And I will post it here. Andreas, do you still have problems with the copy operation? |
| Comment by Andreas Weder [ 23/Mar/05 ] |
|
Michael, thanks for your postings. As of today, the one problem that remains is that I'm allowed to copy a page on itself, which leads to an endless copy op - I have to stop the server. Had no time to fix that yet. I guess it's a simple thing in the GUI. Other than that, copying works fine. I'm using the 2.02 branch. Why are you working on the copy routine. Did you experience problems with 2.02? |
| Comment by Bert Schulzki [ 23/Mar/05 ] |
|
Right, the semantic changed with the fix. With using only the admin interface you wan't notice the change, because the copyied pages will always get an "automatic" name. But when using the api directly, you cannot set the target name of the node anymore. This little change in HierarchyManager works fine for us with the old semantic: public void copyTo(String source, String destination) if (!(lastIndexOfSlash > 0)) { deepCopy(getContent(source), getRootPage(), label); }else { deepCopy(getContent(source), getContent(parent), label); } save(); private void deepCopy(Content source, Content destination, String label) Content content = this.createPage(destination.getHandle(), label); |
| Comment by Philipp Bracher [ 15/Jun/05 ] |
|
current hm.copyTo() uses the jcr workspace copy. if we still have problems this is a jackrabbit thing. Copying binary data seams to work properly. |