-
Bug
-
Resolution: Fixed
-
High (View bug fix roadmap)
-
3.13.2
-
Jira standalone 3.13.2 running on win2k3 server with mysql 5
-
3.13
-
When bulk moving all issues from project SEA to project GENQ all attachments remain in their original folder, and issue key folders are created for both old and new names.
nothing in logfiles at all aside from, which is the message I'd expect to see when it can't find the file. Nothing logged during the bulk move process at all.
2009-01-07 11:57:47,093 http-80-Processor20 ERROR [jira.web.servlet.ViewAttachmentServlet] Error finding /10199/2008y12m23d+-16h20m30s.html: c:\jira\attachments\GENQ\GENQ-22\10199_2008y12m23d - 16h20m30s .html (The system cannot find the file specified)
java.io.FileNotFoundException: c:\jira\attachments\GENQ\GENQ-22\10199_2008y12m23d - 16h20m30s .html (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at com.atlassian.jira.web.servlet.AbstractViewFileServlet.doGet(AbstractViewFileServlet.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.jira.web.filters.AccessLogFilter.doFilter(AccessLogFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.jira.web.filters.SitemeshExcludePathFilter.doFilter(SitemeshExcludePathFilter.java:34)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:192)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.seraph.filter.TrustedApplicationsFilter.doFilter(TrustedApplicationsFilter.java:120)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.seraph.filter.BaseLoginFilter.doFilter(BaseLoginFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.jira.web.filters.ActionCleanupDelayFilter.doFilter(ActionCleanupDelayFilter.java:43)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.jira.web.filters.RequestCleanupFilter.doFilter(RequestCleanupFilter.java:50)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.johnson.filters.AbstractJohnsonFilter.doFilter(AbstractJohnsonFilter.java:72)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:350)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.gzipfilter.GzipFilter.doFilterInternal(GzipFilter.java:81)
at com.atlassian.gzipfilter.GzipFilter.doFilter(GzipFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.core.filters.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:33)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.atlassian.jira.appconsistency.db.DatabaseCompatibilityEnforcerFilter.doFilter(DatabaseCompatibilityEnforcerFilter.java:39)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:619)
- is related to
-
-
- Closed
-
-
-
- Gathering Impact
-
-
JRASERVER-19873 attachment directory structure has exceeded maximum file handles
- Closed
- relates to
-
-
- Gathering Impact
-
[JRASERVER-16223] Bulk move attachments remain in previous project folder
Royce, can you please raise a new Bug report and link it to this issue?
Be sure to mention the exact version of JIRA you are using.
From your comment I am guessing you are using v3.13.x with the patch attached to this Issue?
The patch does not work completely, it moved the image attachments but still left behind the thumbnail file JIRA generated.
Verified with build 3.13.4, its working fine for bulk move of issues from one project to another.
Patch file attached
Only v3.13.2 and v3.13.3 are affected. Do not apply this patch to other versions.
WINDOWS USERS : Do not use the built in Windows ZIP extractor to apply this patch!
By default it replaces all the files in a directory instead of merging the files in.
If this happens, JIRA will not be able to work correctly.
Use another zip tool such as WinZip or 7-Zip.
How to apply this patch
Before applying the patch file, make a copy of your JIRA web application directory in case things go wrong.
This will allow you to more easily back out any changes.
If you are using the Standalone distribution of JIRA:
1. Download the file bulk_move_patch.zip
2. Expand the zip file into <jira_install_dir>/atlassian-jira/ overwriting the files there
3. Restart JIRA
If you are using the WAR distribution of JIRA:
1. Download the file bulk_move_patch.zip
2. Expand the zip file to <jira_install_dir>/webapp overwriting the files there
3. Run 'build.sh clean' on unix or 'build.bat clean' on windows
4. Run 'build.sh' on unix or 'build.bat' on windows
5. Redeploy the JIRA web app into your application server
Neal,
Just to be clear, this bug does not effect 3.13 (.0), or 3.13.1; only 3.13.2 and 3.13.3.
It will be fixed in 3.13.4, and I will be uploading a patch here for affected versions fairly soon.
Let us know if there will be a patch for this for 3.13. We are looking to upgrade next week.
Thanks
This problem is caused when you move an issue to a new project with a different workflow.
During the workflow migration, the issue saves the new Project ID into the DB.
Now, because of the changes introduced to fix JRA-15475, when we "reload" the issue, it gets the target project, which is incorrect in this case, and no attachments get moved.
If the workflow doesn't change, then this problem does not happen.
Diego Alonso [Atlassian]
added a comment - When moving issue PR-20 to project TODO, the attachment is originally located at PR/PR-20/10040_filename.
String originalFilePath = applicationProperties.getString(APKeys.JIRA_PATH_ATTACHMENTS) + "/" + issue.getProject().getString("key") + "/" + issue.getKey() + "/" + fileName;
The function call issue.getProject().getString("key") is returning project TODO, so the originalFilePath is incorrectly set to TODO/PR-20/10040_filename, and the move fails.
As requested in JRA-15475:
At the very least, the BulkMoveOperation.moveAttachments function should check whether the renameTo function succeeds or fails, and log an error message if failure.
Diego Alonso [Atlassian]
added a comment - When moving issue PR-20 to project TODO, the attachment is originally located at PR/PR-20/10040_filename .
BulkMoveOperation.java
String originalFilePath = applicationProperties.getString(APKeys.JIRA_PATH_ATTACHMENTS) + "/" + issue.getProject().getString( "key" ) + "/" + issue.getKey() + "/" + fileName;
The function call issue.getProject().getString("key") is returning project TODO, so the originalFilePath is incorrectly set to TODO/PR-20/10040_filename , and the move fails.
As requested in JRA-15475 :
At the very least, the BulkMoveOperation.moveAttachments function should check whether the renameTo function succeeds or fails, and log an error message if failure. Diego Alonso [Atlassian]
added a comment - This issue is not a duplicate. There is no need for parallel bulk move. Reproducing the problem is as simple as doing a bulk move between projects for an issue with attachments. The attachments are always lost, left behind in the previous project.
Diego Alonso [Atlassian]
added a comment - This issue is not a duplicate. There is no need for parallel bulk move. Reproducing the problem is as simple as doing a bulk move between projects for an issue with attachments. The attachments are always lost, left behind in the previous project. 
This also affects 4.1.1. See Single and Bulk issue moves do not move attachment thumbnails properly
http://jira.atlassian.com/browse/JRA-21374