-
Bug
-
Resolution: Fixed
-
High
-
6.0.0, 7.0.0, 7.4.7, 7.13.7
-
32
-
Severity 2 - Major
-
120
-
We don't plan to backport the fix for this bug to earlier Long Term Support versions
The fix for this bug isn't suitable for backporting to a bug fix release for any previous LTS versions. This is often because the fix is considered too high risk to implement in an older version.
The fix for this issue will be included in future Long Term Support versions.
Issue Summary
This ticket tracks a class of bugs wherein Confluence misplaces attachments as part of a page move. The attachments remain on disk, but due to being in the wrong part of the file tree, appear to be missing.
This issue occurs during page or pagetree moves that are unexpectedly interrupted.
Note this is not related to CONFSERVER-55928: Attachments become 'Unknown Attachment' in the page editor with Collaborative Editing turned on or its related bugs
Steps to Reproduce
There are currently multiple causes with differing reproduction steps.
The fundamental cause is halting a pagetree copy whilst attachments are being moved.
Expected Results
The files should be moved successfully. In the case of a failed move, the file copies should be rolled back successfully.
Actual Results
The files are not moved correctly, or alternately, the files are not rolled back to their original location in the case of a failed page move.
Workaround
We currently have a script that searches for attachments that have been misplaced and moves them back to the correct location. The script can be found at https://confluence.atlassian.com/confkb/how-to-resolve-missing-attachments-in-confluence-201761.html
- is related to
-
CONFSERVER-56060 Page Move feature should be more stable
- Short Term Backlog
- relates to
-
CONFSERVER-66568 Re-trying a failed space page move does not merge missing attachments
- Closed
- mentioned in
-
Page No Confluence page found with the given URL.
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
a7e9ce396f68 thank you for your feedback. The decision was made based on few factors.
First of all the performance of the migration process. Most of operations usually go through NFS which is a bottle neck. Using only a file system move operation made it possible to have the migration process completed much faster. Calculating binary diff could significantly slow down the migration as well as it could take more memory risking crash. Imagine calculating a diff of 4GB video file!
Secondly development time. We were not sure how many duplicates customers can have and how many of them are exactly the same.
Thirdly, we didn't want to risk losing any file so we decided to limit ourselves to move operations only. Avoiding any deletes.
Based on these we decided that duplicates can be safely handled by admins. Either left as they are, or reviewed in their time, not slowing down the migration.