Change of behaviour regarding duplicate attachment filenames

Confluence Development Confluence Cloud
1

I’m pretty sure that attachments with duplicate filenames used to behave like this:

  • When trying to rename an attachment through the Confluence UI to a filename that is already taken by another attachment, an error was shown.
  • When uploading a file through the Confluence UI or the REST API and another attachment with the same filename already existed, a new attachment with a new content ID was created and one ended up with duplicate filenames.
    • Because <ri:attachment> links reference attachments by filename, such references would randomly point to one of the two files. It was for example not possible to include two images with the same filename on a page. Instead, one of them would be shown twice.
    • Because the attachments had different IDs, it was possible to rename one of them using the Confluence UI or REST API, without any impact on the other attachment. This would solve the duplicate filename issue.

The behaviour that I am seeing now:

  • When trying to rename an attachment through the Confluence UI to a filename that is already taken by another attachment, an error is still shown.
  • When uploading a file through the Confluence UI or the REST API and another attachment with the same filename already exists, that attachment is replaced with the new one. The attachment ID doesn’t change, but a new version of it is created. The old version(s) can still be accessed through the Confluence UI or /rest/api/content/${attachmentId}/version, the file can be downloaded through /download/attachments/${attachmentId}/${filename}?version=${version} (the attachment ID without the att prefix in this case).

I am wondering when this was changed and whether it was announced anywhere and I missed it.

It is breaking a feature in our app where we copy the attachments of multiple pages onto a single page. Until now, we have been using the Copy Single Page API with copyAttachments and an existing_page destination to copy all the attachments. That call was creating duplicate attachments in case of a filename conflict, which we would resolve after the copy operation by renaming those attachments. Now we will have to change that logic, probably we will have to rename attachments before the operation, as afterwards we have no way to restore the overwritten versions of attachments into new files.

1 Like
2

Hi @candid,

When you say “uploading a file through the REST API”, are you referring to the “Copy Single Page API” or the “Create or update attachment”? If it’s “Copy Single Page API”, then we had a bug fix deployed around mid-April 2020 that creates a new version of the attachment instead of creating a new attachment content every time when doing a single page copy to an existing_page.

Thanks,
Ryan

1 Like
3

That’s good to know, thank you. Was this change announced anywhere?

I’ve done some more testing and still don’t completely understand how it works. Filenames in Confluence are case-insensitive, so if a page references an attachment A.jpg but only has an attachment a.jpg, it is still shown correctly. Trying to rename a.jpg to A.jpg through the Confluence UI results in a “This file name already exists” error, but I can rename it to a2.jpg and then to A.jpg.

Uploading a file A.jpg to a page that has an a.jpg attachment through the Confluence UI results in a new version of a.jpg, rather than creating a separate attachment. However, copying a page that has an attachment A.jpg onto a page that has an attachment a.jpg using the Copy Single Page API results in two separate attachments. Confluence seems to be able to distinguish the two, but some weird things seem to be happening (when embedding A.jpg into the page, it points to the right image when looking at the view format through the REST API, but in the Confluence UI it renders with an error).

What I also noticed (although it doesn’t affect us, as we are using the API in a different way) is that when using the Copy Single Page API to replace an existing page, references to attachments in the replaced page still point back to the source page (like <ac:image><ri:attachment ri:filename="A.jpg"><ri:page ri:space-key="AT" ri:content-title="Source page"/></ri:attachment></ac:image>). What’s the point of copying the attachments if the copied attachments are then not referenced? Maybe the expected usage is to provide a custom body in that case to reference the copied attachments.

It would be really nice if the exact behaviour regarding attachments and duplicate attachment filenames could be documented in the documentation for the Copy Single Page API.