При обновлении выходит - Ошибка при выполнении файловой операции

Сталкивался с такой же проблемой, при чем с несколькими базами у разных клиентов, конфигурации Бухгалтерия 3.0 и ЗУП 2.5, базы серверные MSSQL. Проблема в том, что по каким-то причинам "рушится" конфигурация поставщика. При этом в настройке поддержки она показывается как правильная версия, но при попытке сравнить с конфигурацией поставщика или сохранить ее в файл, тоже вылетает эта же ошибка, при попытке открыть конфигурацию поставщика - ошибка и открывается пустая конфигурация. Предыдущие обновления проходили в штатном режиме, без ошибок. Т.е. причина ошибки не понятна. Лечил как уже писали выше, снятием с поддержки и загрузкой типовой конфигурации через Загрузить конфигурацию. Если база измененная, подготавливаем типовую, в нее добавляем свои объекты, обязательно копи-пастом и загружаем. С двумя такими базами все норм. С одной проблема повторилась через два-три обновления. В одной базе при загрузке типовой конфигурации не находило соответствия нескольким регистрам сведений, т.е. удаляла существующий и добавляла новый из типовой. В моем случае было не критично, но возможна потеря данных, так что не забываем бэкапиться перед исправлениями.

Недавно столкнулся с такой проблемой. Рухнула конфигурация поставщика, как оказалось позднее проблема была в справочнике номенклатура. Была достаточно переписана, по этому вариант с загрузкой типовой конфигурации отпадал, так как терялись данные в добавленных реквизитах с 2014 года. База данных в скуле. Решилось всё достаточно просто:
1. Снял с поддержки через меню конфигурация, настройка поддержки(очень важный момент, применение изменений не делал);
2. Далее через сравнение и объединение объединил с подготовленной типовой cf-кой того же релиза. В этот момент он спрашивает о возможности поставить на поддержку, соглашаемся.
3. Принятие изменений, отладка. Как раз в момент отладки вылетело служебное сообщение о номенклатуре.
4. Обновление до текущего релиза.
Прошло уже 2 обновления, полет нормальный.

Последнее время регулярно с этим сталкиваюсь. Скачиваю обновления, разворачиваю на съемном диске, устанавливаю, копирую CFU. Потом готовую папку отправляю в облако. Пытаюсь обновить с диска - файловая ошибка, нет доступных обновлений, а когда взял из облака, отлично обновилось. Ну ладно, повредился файл. Взял в облаке, скопировал к себе. Не обновляет. Сравниваю, размер один в один, еще раз копирую, фиг. Из облака отлично обновляет. Начал грешить на диск. Перенес данные, проверил диск, форматнул на всякий случай, вернул. Возвращал в другом порядке. Заработало. Скачал следующее, опять тоже, с этого диска отнес на облако. С диска не работает, с облака пожалуйста. Ладно умер диск, отложил взял другой, другой фирмы, другого размера. Сегодня та же хрень.Развернул на диске, скопировал в облако. На диске не работает, в облаке чудесно. Стер папку, скачал обновление вновь, развернул, достал CFU - НЕ РАБОТАЕТ. Ну не могут два диска одинаково умереть. Причина в чем-то другом.

Мучаемся с этим уже пару лет. Конфигурация УПП 1.3, на поддержке с возможностью редактирования. База на MSSQL 2008R2. Запрос в техподдержку результата не не дал. Недельная переписка. отправка базы и т.п.
Платформа 8.3.10, началось еще с 8.2. Разницы никакой. Танцы с бубном вокруг снятия/установки поддержки, обновления в штатном режиме и через некоторое время все по новой. Держу на готове пустую базу с типовой последнего установленного релиза. Выгружаю оттуда конфигурацию поставщика и накатываю на свою.
Надоело просто жуть. Но решения так и не нашли пока.

Уж по скольку занялся этой темой выложу свои мысли, так сказать в качестве "Бреда" сюда.
Анализировал таблицу [dbo].[Config] . На сколько мне известно самая жирная запись и содержит конфигурацию поставщика (но это не точно :) ). Технология хранения мне мало известна, по этому все сказанное лишь догадки.
Так вот, в испорченной базе, в этой самой жирной сроке (у меня она больше 314 мб) обнаружил, что большая часть этой строки (72%) состоит из повторяющихся блоков "3C2D554E494E495449414C495A45442D3E". В копии базы того же релиза этого нет.
Выгрузил ее сначала в символьном виде.
Потом выгрузил в бинарном виде и понял, что текст "<-UNINITIALIZED->".
Проводил эксперимент с копией базы. Если снимать конфигурацию с поддержки, то эта строка полностью не очищается. Становится меньше значительно, но полностью не очищается. Могу предположить, что в ней живет не только конфигурация поставщика. И удалять ее (как читал где-то в интернетах) я бы не стал, дабы не грохнуть рабочую конфигурацию.
Суть задумки проста. Хочу хранить конфигурацию поставщика в резерве и в случае такой напасти опять, просто скопировать в нужное место. (мало вероятно, но вдруг прокатит) Уж больно надоело танцевать с бубном.
Остались вопросы.
1. Где почитать про технологию хранения метаданных 1С v8.3 (SQL)?
2. Какова природа возникновения этой проблемы?
3. Не виновато ли в этом динамическое обновление конфигурации?

Столкнулся с такой же проблемой. Что сделал:
1. Взял типовую конф-ю того же релиза
2. Включил в ней возможность редактирования с сохранением поддержки для всех объектов
3. Натянул на нее cf сохраненный из проблемной базы, принял изменения
4. Сохранил конф-ю после объединения
5. Загрузил сохраненную конф-ю в проблеммную базу, принял изменения (при принятии были предупреждения, похоже это те объекты метаданных, которые умерли в конф-ии поставщика)
6. Профит, обновление прошло нормально.

снять с поддержки, загрузить cf такого же релиза, база встанет на поддержку сама и, после загрузки cf, можно обновляться дальше без проблем.
на sql все отработало.

А я сформировала файл обновления (чтобы все настройки сохранились), потом его же загрузила через "загрузить конфигурацию". И потом дальше обновляла без проблем. Отработало на файловом режиме

Тоже столкнулся с ошибкой "Ошибка выполнения файловой операции". При попытке обновить конфу файлом .cfu поставщика (Поддержка - Обновить конфу).
Так же, решилось восстановлением конфигурации поставщика.

Порядок по памяти:
1) сохранил имеющуюся конфу в .cf
2) загрузил конфу поставщика (.cf) с поставкой на поддержку (изменения не принимал)
3) включил в конфе возможность редактирования с сохранением поддержки для всех объектов
4) накатил свои наработки из конфы .cf на (1) шаге с помощью сравнения-объединения
5) принял изменения