4

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:

Community
  • 1
  • 1
Mr Smith
  • 3,318
  • 9
  • 47
  • 85

3 Answers3

8

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.

Nuno Linhares
  • 10,214
  • 1
  • 22
  • 42
  • Everything in this case is being published to the filesystem. I see the data folder has some references to 1001. Maybe that's it? I said before that I unpublished everything, but maybe I need to unpublish everything, empty out the remnants in the Data folder & then republish – Mr Smith Feb 13 '13 at 19:20
  • If deleting the data folder is an option for you, then yes, go for it :) – Nuno Linhares Feb 13 '13 at 19:24
  • this is just our test server...so it's an option for now. I think we need to find out exactly why this is happening & make sure it doesn't happen in prod – Mr Smith Feb 13 '13 at 19:26
  • Success...I unpublished & then removed the stray entries in the Data folder. this fixed the issue. I'll post the exact steps that were followed to create the problem in the first place when I find them. – Mr Smith Feb 13 '13 at 20:58
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().

Dominic Cronin
  • 6,062
  • 2
  • 23
  • 56
  • An immediate fix for the error on an author's side is to rename the uploaded filename for the new file. Otherwise another programmatic approach is using folder path rather than the default "images" location to reduce the chance of duplicates. – Alvin Reyes Feb 14 '13 at 02:53
  • ...also common in training when you ask a class to upload an example image. :-) – Alvin Reyes Feb 14 '13 at 02:55
  • 1
    There should at least be an over-ride setting for this behavior in the deployer config file. I'd say that a good percentage of the time, binaries with the same name are the same binary, and I think that would be easy to explain to the users. In my case, my concern is that Tridion seems to have lost track of what it has published. Keep in mind my scenario, I'm getting this error because of a binary that was deleted from the CM. – Mr Smith Feb 14 '13 at 12:25
  • Yes - it's annoying that the CM doesn't "remember" which binaries are published where, and seems to leave this up to CD. You can see why, because binaries are commonly just published out with the page or component that uses them. As Nuno pointed out, the CD side is supposed to keep track of it, but as with any synchronising action, it can go wrong. If that happens, I suppose manual deleting is the way forward. It's good that you've already called in support. They will be able to help you through the process. – Dominic Cronin Feb 14 '13 at 13:03
0

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

MDa
  • 579
  • 2
  • 10