Attempting to deploy a binary to a location where a different binary is already stored Existing binary

Question

I'm receiving the error below. I see this referred to in other SO posts (here) & I contacted SDL support, but I'm still having trouble fixing the problem. Can someone offer an EASY solution? I think the steps that lead to this are as follows:

1) publish page with link to PDF 1001.
2) Remove PDF 1001 from page & delete it from the CM
3) upload PDF 1002 with same name as 1001.
4) Now if you try & publish you will get the error.

So I need to unpublish PDF 1001 but it has been deleted from the CM. How can I fix this problem? SDL support recommended a fix involving editing the ZIP file generated during the publishing transaction. But I went as far as unpublishing all pages of the publication & verified that they were gone. The error persists...

ERROR: Phase: Deployment Prepare Commit Phase failed, Unable to prepare transaction: tcm:0-11111-66560, Attempting to deploy a binary 1002 to a location where a different binary is already stored Existing binary: 1001:, Attempting to deploy a binary 1002 to a location where a different binary is already stored Existing binary: 1001:, Unable to prepare transaction: tcm:0-13573-66560, Attempting to deploy a binary 1002 to a location where a different binary is already stored Existing binary: 1001:, Attempting to deploy a binary 1002 to a location where a different binary is already stored Existing binary: 1001:

Answer 1

So the file was deleted from CM, but CD still has a reference to it (according to CD it still exists and is still used by something).

You should publish the page after you remove 1001 but before you add 1002. This should remove the reference from the CD database. Then you should be OK to add 1002 and publish the page again.

[EDIT] Sorry, only read now that you say you unpublished everything. Clearly not, as there is still a reference to it... opening a VM, will be back with updates.

[EDIT2] Still don't understand how it remains a conflict if you unpublish, but this is what I observe on my server:

• Add binary to page, publish
  • Reference added to "REFERENCE_ENTRIES" table in CD
• Remove binary from page, publish
  • Reference removed from "REFERENCE_ENTRIES" table, binary deleted
• Unpublish page (after re-adding binary, republishing)
  • Reference removed from "REFERENCE_ENTRIES" table, binary deleted

So, in my case I'm seeing what I would expect. Give it a try publishing the page after you removed the binary, and if possible go check what's in the REFERENCE_ENTRIES table.

Answer 2

This error is often caused by the fact that by default, Tridion uses the original filename of an uploaded binary as its filename on the Content Delivery side. If you aren't specifying a distinct structure group to deploy to, then if you have two multimedia components with the same original upload filename, Tridion will try to deploy them to the same location on content delivery. Fortunately, the Content Delivery libraries are smart enough to detect a potential over-write, and instead, you get this error.

Firstly - this scenario is way more likely in testing situations. For example, you need to create a bunch of test MMCs, so you copy and paste some that you already have. Guess what - their upload filenames will be the same.

The solution is to ensure that the filename is unique in the structure group you're deploying to. You have a lot of choice about how to do this, but a common approach is to introduce the component ID into the filename when you call AddBinary().

Answer 3

We encounter this failsafe pretty much every install. While sure, it is a lot more common on development and testing environments, the failsafe can happen in other situations as well. In fact, it can effectively break your entire site if you try and publish an image that's already there (where images are being replaced by the imfamous 'broken image' icon). Not sure how that works, but it can.

To make absolutely sure that uploaded binaries are posted are unique, I'd recommend writing a TBB that checks all binaries and adds the tcm uri to the filename. Add this on every page template to ensure this does not happen. The sooner you do this, the less likely the error occurs. Do bear in mind that this might mean that the upload will always publish a new binary, and if you add the tbb to COMPONENT templates, pages tend to get conflicted. However, it will save you the hassle of explaining the workflow to editors who don't understand (or better, accept) the failsafe.

this page might help you get started: Unique Binary filenames