Imported attachments can not be opened after import

[Hackbarth_ Tim]

Hello community,

we are importing issues via CSV export from an older Jira (version 7.7) to a newer instance (version 8.20).
The old Jira is running on a Windows system while the new Jira is running on an Ubuntu 20.04 server.

The attachments are correctly linked in the issues and also have the correct filesize, yet when we download the attachments and try to open it we get an error.

The links for the attachments are the same as other files.

Broken attachment: https://jira.company.de/secure/attachment/227874/2019-08-07%2010_56_53-DIZ%20PDB.png 

Working attachment: https://jira.company.de/secure/attachment/229180/test.txt

I have already checked the file permissions and have reindexed Jira but the problem persisted.

I would be thankful for some input to solve this issue.

Thanks

[Ismael Jimoh]

Good day @Hackbarth_ Tim 

To migrate attachments via a CSV import, you either:

1. Store the attachment files on the new server in a directory the user running Jira can reach and read from or
2. You host it on an accessible URL link where the files can be read from and correctly mapped to the issue.

Could you confirm which of these methods was used in your case?

Also, we’re there any error or warnings during the import?

I will start my investigation from here.

To fix this you could import the attachments again using issue key and the expected attachment link.

This should update the issue creating a new attachment.

Rgds

[Hackbarth_ Tim]

Hello @Ismael Jimoh

thanks for the quick response.

We are storing the attachment files on the same server that Jira is running on.
The directory is owned by the jira user, so it can access the attachments.

The problem only occured with one project.
The attachments in other projects are working fine and they are stored in other directories at the same location.

During the import I only received some warnings regarding the date format.
But this was for the comments and no the attachments.

[Ismael Jimoh]

Thanks for the update and clarification.

Could it be the files got corrupted? If you remove and then upload the files to the server again and then perform the CSV import.

Does the issue occur for all issues in the affected project or does it happen only for some issues?

What is thrown in Jira log when you open the file.

[Hackbarth_ Tim]

Hello @Ismael Jimoh

I have tried your suggestion but to no avail.

I have downloaded the attachement directory for the specific project and imported this manually into the attachement directory on the target system.
After this I performed the csv import, yet i have the same errors.

I double checked all file permissions and owners, which all matched the other working attachments.

I have also checked the log during the import and i only get an warning regarding a parsing error for the date.

Cannot parse '23/Mar/18 7:15 AM;max.mustermann@sz.de;Ressorts.PNG;http:/jira.company.de/secure/attachment/34697/Ressorts.PNG' as attachment info: Unparseable date: "23/Mar/18 7:15 AM"
Cannot parse '23/Mar/18 7:14 AM;max.mustermann@sz.de;Ressorts.PNG;http://jira.company.de/secure/attachment/34696/Ressorts.PNG' as attachment info: Unparseable date: "23/Mar/18 7:14 AM"

If I open the broken attachements I can not see any logs being created.
So it is hard to provide some additional informations here.

The problem is affecting all attachements in all tickets.

[Ismael Jimoh]

Can you check if there were any dates parsed during the import and if yes, does it match what Jira expects?

Compare this if possible to dates in other imports that worked.

What happens in the browser console when the said attachment is opened. This is really an unusual behaviour 

[Hackbarth_ Tim]

Hi @Ismael Jimoh

I compared the project pre and post import and all dates for all tickets and attachements are correctly parsed.

However I also noticed that some attachements are missing.
I checked the error messages from the last import and this is because the date could no be parsed.

Cannot parse '23/May/17 9:13 AM;max.mustermann@sz.de;Beispiel ocr-Erkennung.PNG;http://jira.company.de/secure/attachment/30194/Beispiel+ocr-Erkennung.PNG' as attachment info: Unparseable date: "23/May/17 9:13 AM"

The corresponding field in the csv is:

http://jira.company.de/secure/attachment/30194/Beispiel+ocr-Erkennung.PNG,23/May/17 9:13 AM

The set date format during the import was

dd/MMM/yy h:mm a

What's odd is that alle date have the same format, but a few dates where not parsed.

Regarding the browser console.
When I open a ticket and the attachment, the only output I get a 404 for a specific script runner.
I double checked this with ticket we created in other projects and the 404 also appeared in the console.

So I would rule that out as a reason.

So you have an idea why the date is not parsed?

[Ismael Jimoh]

Hi @Hackbarth_ Tim 

Sorry for the late reply.

I’m looking at the attachment section and  I can’t understand why it isn’t parsed. Especially if you say that the same format was used in other project imports and there were no issues importing the attachments.

I do notice that you are using semi-colons instead of commas as your separator and would like to ask if in the other imports, this was also used and if the separator specified during the import process was a semicolon and not a comma.

Other than these, I can’t think of a reason this isn’t working as expected.

[Hackbarth_ Tim]

Hello @Ismael Jimoh

I took a look at both jira instances.

The delimeter that is the standard for jira is a comma.
I also didn't found any way to configure the delimeter during the export.
The CSV supports this, as all field are seperated via commas and the semicolons are only

For the import I used the default setting, which is also the comma.

I think the semicolons are part of the attachement and comment fields to seperate the user, date and comment body/attachement link which comment/uploaded.

Do you know a way to change the seperator during the export?
I could try to use a seperator which is not a comma or semicolon to rule this out as a reason.