Попытка развернуть двоичный файл в месте, где уже хранится другой двоичный файл Существующий двоичный файл

Я получаю сообщение об ошибке ниже. Я вижу, что это упоминается в других сообщениях SO (здесь) и я связался со службой поддержки SDL, но мне все еще не удается решить проблему. Может ли кто-нибудь предложить ПРОСТОЕ решение? Я думаю, что шаги, которые ведут к этому, следующие:

1) опубликовать страницу со ссылкой на PDF 1001.
2) удалить PDF 1001 со страницы и удалить его из CM
3) загрузить PDF 1002 с тем же именем, что и 1001.
4) Теперь, если вы попробуете & опубликовать, вы получите ошибку.

Поэтому мне нужно отменить публикацию PDF 1001, но он был удален из CM. Как я могу решить эту проблему? Служба поддержки SDL рекомендовала исправление, связанное с редактированием ZIP-файла, созданного во время транзакции публикации. Но я дошел до того, что удалил все страницы публикации и убедился, что они исчезли. Ошибка сохраняется...

ОШИБКА: Этап: Фаза подтверждения развертывания не удалась, Не удалось подготовить транзакцию: tcm:0-11111-66560, Попытка развернуть двоичный файл 1002 в место, где уже хранится другой двоичный файл Существующий двоичный файл: 1001 :, Попытка развернуть двоичный файл 1002 в место, где уже хранится другой двоичный файл Существующий двоичный файл: 1001:, Невозможно подготовить транзакцию: tcm:0-13573-66560, Попытка развернуть двоичный файл 1002 в место, где другой двоичный файл уже сохранен Существующий двоичный файл: 1001:, Попытка развернуть двоичный файл 1002 в место, где уже хранится другой двоичный файл Существующий двоичный файл: 1001:


tridion tridion-2011 tridion-content-delivery
person Mr Smith    schedule 13.02.2013    source источник

Ответы (3)


arrow_upward
8
arrow_downward

Таким образом, файл был удален из CM, но на CD все еще есть ссылка на него (согласно CD, он все еще существует и до сих пор чем-то используется).

Вы должны опубликовать страницу после удаления 1001, но до добавления 1002. Это должно удалить ссылку из базы данных CD. Затем вы должны быть в порядке, чтобы добавить 1002 и снова опубликовать страницу.

[РЕДАКТИРОВАТЬ] Извините, я прочитал только сейчас, когда вы сказали, что все отменили. Ясно, что нет, так как ссылка на него все еще есть... открыв виртуальную машину, мы вернемся с обновлениями.

[EDIT2] До сих пор не понимаю, как остается конфликт, если вы отменяете публикацию, но вот что я наблюдаю на своем сервере:

  • 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

Итак, в моем случае я вижу то, что и ожидал. Попробуйте опубликовать страницу после удаления двоичного файла и, если возможно, проверьте, что находится в таблице REFERENCE_ENTRIES.

person Nuno Linhares    schedule 13.02.2013
comment
В этом случае все публикуется в файловой системе. Я вижу, что в папке с данными есть некоторые ссылки на 1001. Может быть, это все? Я уже говорил, что отменил публикацию всего, но, возможно, мне нужно отменить публикацию всего, вычистить остатки в папке «Данные» и затем опубликовать повторно. - person Mr Smith; 13.02.2013
comment
Если вам подходит удаление папки с данными, то да, сделайте это :) - person Nuno Linhares; 13.02.2013
comment
это всего лишь наш тестовый сервер... так что пока это вариант. Я думаю, нам нужно выяснить, почему именно это происходит, и убедиться, что этого не происходит в продукте. - person Mr Smith; 13.02.2013
comment
Успех... Я отменил публикацию, а затем удалил случайные записи в папке "Данные". это устранило проблему. Я опубликую точные шаги, которые были выполнены, чтобы создать проблему в первую очередь, когда я их найду. - person Mr Smith; 14.02.2013

arrow_upward
2
arrow_downward

Эта ошибка часто возникает из-за того, что по умолчанию Tridion использует исходное имя загруженного двоичного файла в качестве имени файла на стороне доставки контента. Если вы не укажете отдельную структурную группу для развертывания, то при наличии двух мультимедийных компонентов с одинаковым исходным именем загружаемого файла Tridion попытается развернуть их в одно и то же место при доставке контента. К счастью, библиотеки доставки контента достаточно умны, чтобы обнаружить возможную перезапись, и вместо этого вы получаете эту ошибку.

Во-первых, этот сценарий более вероятен в тестовых ситуациях. Например, вам нужно создать несколько тестовых MMC, поэтому вы копируете и вставляете те, которые у вас уже есть. Угадайте, что — их имена загружаемых файлов будут одинаковыми.

Решение состоит в том, чтобы обеспечить уникальность имени файла в группе структур, в которой выполняется развертывание. У вас есть большой выбор того, как это сделать, но общий подход заключается в том, чтобы ввести идентификатор компонента в имя файла при вызове AddBinary().

person Dominic Cronin    schedule 13.02.2013
comment
Немедленным исправлением ошибки на стороне автора является переименование загруженного файла для нового файла. В противном случае другой программный подход использует путь к папке, а не расположение изображений по умолчанию, чтобы уменьшить вероятность дублирования. - person Alvin Reyes; 14.02.2013
comment
...также часто встречается в обучении, когда вы просите класс загрузить пример изображения. :-) - person Alvin Reyes; 14.02.2013
comment
По крайней мере, для этого поведения должен быть параметр переопределения в файле конфигурации развертывания. Я бы сказал, что в большом проценте случаев двоичные файлы с одинаковыми именами являются одним и тем же двоичным файлом, и я думаю, что это будет легко объяснить пользователям. В моем случае меня беспокоит то, что Tridion, кажется, потерял след того, что он опубликовал. Имейте в виду мой сценарий, я получаю эту ошибку из-за бинарного файла, который был удален из CM. - person Mr Smith; 14.02.2013
comment
Да, раздражает, что CM не помнит, какие бинарные файлы где опубликованы, и, похоже, оставляет это на усмотрение CD. Вы можете понять, почему, потому что двоичные файлы обычно просто публикуются вместе со страницей или компонентом, который их использует. Как указал Нуно, сторона CD должна следить за этим, но, как и в случае любого синхронизирующего действия, оно может пойти не так. Если это произойдет, я полагаю, что ручное удаление — это путь вперед. Хорошо, что вы уже позвонили в поддержку. Они смогут помочь вам в этом процессе. - person Dominic Cronin; 14.02.2013

arrow_upward
0
arrow_downward

Мы сталкиваемся с этим отказоустойчивым практически при каждой установке. Конечно, это гораздо чаще встречается в средах разработки и тестирования, отказоустойчивость может произойти и в других ситуациях. Фактически, это может эффективно сломать весь ваш сайт, если вы попытаетесь опубликовать изображение, которое уже есть (где изображения заменяются печально известным значком «сломанное изображение»). Не уверен, как это работает, но может.

Чтобы быть абсолютно уверенным, что загружаемые двоичные файлы являются уникальными, я бы рекомендовал написать TBB, который проверяет все двоичные файлы и добавляет tcm uri к имени файла. Добавьте это в каждый шаблон страницы, чтобы этого не произошло. Чем раньше вы это сделаете, тем меньше вероятность возникновения ошибки. Имейте в виду, что это может означать, что загрузка всегда будет публиковать новый двоичный файл, и если вы добавите tbb в шаблоны COMPONENT, страницы могут конфликтовать. Тем не менее, это избавит вас от необходимости объяснять рабочий процесс редакторам, которые не понимают (или, лучше, не принимают) отказоустойчивость.

эта страница может помочь вам начать работу: Уникальные имена двоичных файлов

person MDa    schedule 15.02.2013