Не открываются файлы .ods, выдает "импорт текста". Как быть?

[cultura10]

Всем добрый день!

Итак, что случилось:
Есть 3 файла .ods, которые были созданы в OO, и только им и использовались - открывались и редактировались без проблем в течение нескольких месяцев.
Некоторое время назад я работал с ними одновременно. Все было, насколько помню, штатно.
Сейчас, при попытке открыть эти файлы - два из них предлагают "импорт текста" (вложено), третий спрашивает "восстановить документ?", если нажать "восстановить", то открывается пустой файл.
Изначально все 3 файла на превью отображали то, что у них внутри, после нескольких попыток открыть файлы теперь отображается просто ярлык Calc.

Все три файла имеют вес: 45, 72, 290 КБ.
Макросов нет.

Что было испробовано:
1. Открытие через OO и Libre.
2. Собственно импорт текста с всевозможными настройками: Кириллица, Юникод, UTF-8 и проч. Итог: OO "не отвечает", Libre открывает с нечитабельными знаками.
3. look-ов нет.
4. Starus Excel Recovery эти файлы не находит.
5. Google Таблицы не открывают.

Сами файлы выложить не могу - ком-ая информация.

Есть ли еще какие-либо варианты оживить файлы?

Спасибо!

[bormant]

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

Посмотреть, куда производилось резервное копирование другими средствами, поднять файлы из резервной копии.

Выслать файлы мне на bormant собак mail точка ru, но 99 из 100, что повреждения необратимы.

[cultura10]

Папка backup пуста, к сожалению.
Файл на почту вам вышлю.

Спасибо!

[kompilainenn]

bormant: повреждения файлов - это следствие работы офиса или сбой файловой системы или жесткого диска?

где-то я уже видел подобную тему

[greenman]

31 марта -- всемирный день бэкапа....

[cultura10]

где-то я уже видел подобную тему

Подобная тема была моя же, там решение было найдено. Нынешняя ситуация отличается.

[rami]

где-то я уже видел подобную тему

Подобная тема была моя же, там решение было найдено. Нынешняя ситуация отличается.

Конечно, отличается, первый раз это была трагедия — не делали резервных копий, а сейчас уже фарс. Почему не делали резервные копии?

[cultura10]

Конечно, отличается, первый раз это была трагедия — не делали резервных копий, а сейчас уже фарс. Почему не делали резервные копии?

Про возможность офиса делать автокопии, и как это включить, узнал после нынешней проблемы.
Бекап файлов есть на флешке, но он устаревший на несколько месяцев.
Если бы удалось "починить" файлы, это конечно было бы замечательно.

[rami]

Про возможность офиса делать автокопии, и как это включить, узнал после нынешней проблемы.

Эта возможность по умолчанию, не нужно было отключать.

Бекап файлов есть на флешке, но он устаревший на несколько месяцев.

А флешка в яйце, яйцо на дереве, а дерево в дремучем лесу... — эти сказки я в прошлом тысячелетии читал. При сохранении важных данных не должно быть никаких отговорок. Есть несколько способов сохранять данные:
1. офисный бэкап — я сейчас этим не пользуюсь
2. резервное копирование системного диска — на Маке это самый простой способ, пользуюсь. На других осях тоже есть.
3. простое дублирование важных файлов — это тоже простой способ с минимум ручной работы, тоже пользуюсь. Создаётся папка с именем "Архив" в удобном месте и в неё бросается дубликат важного файла, после следующего изменения файла создаётся новый дубликат и бросается в ту же архивную папку, выскакивает окошко с сообщением, что файл с таким именем уже есть в папке и предлагается решить что делать — заменить старый новым или оставить оба, заменяйте, чтобы в папке был всегда свежий дубликат.

[greenman]

... заменяйте, чтобы в папке был всегда свежий дубликат.

С немалой вероятность получить -- "вчера всё работло, сохранился, сделал копию, а сегодня ничего не открывается".

Резервных копий должно быть больше одной.

А топикстартеру проверить бы железо. Когда на пустом месте время от времени  возникают ошибки -- это неспроста.

[cultura10]

А топикстартеру проверить бы железо. Когда на пустом месте время от времени  возникают ошибки -- это неспроста.

А что, навскидку из реального, может быть?

[cultura10]

Подскажите, риск подобной ситуации одинаково велик со всеми форматами файлов? -- .xls не более надежен?

[bormant]

Я тут немного сгущу краски, не возражаете?

При подобных ошибках в результате наблюдаю обычно одну и ту же картину: первые 32768 (0x8000) байт оказываются нулевые, что обычно приходится на content.xml.
В данном случае сжатый content.xml оказался размером больше очищенного участка, от него остался весьма приличный хвост. Посему возникла у меня крамольная мысль -- а нет ли возможности как-то распаковать оставшееся.
Первым делом пробежался по утилитам, реконструирующим битые ZIP. Чего-то подходящего с наскока не обнаружилось, возможности их в основном сводятся к перепаковке неповрежденных файлов из архива, что поставленную задачу не решает.
Почитал RFC на сжатие deflate, вроде бы есть шанс попасть на начало блока, от которого далее возможно распаковать остаток потока. Собрался было писать распаковщик, пытающийся начинать с произвольного места, да наткнулся на вот эту страничку:
http://www.compression.ru/forum/messages/1455.htm
где описано ровно то, что требовалось, а ниже и сообщение со ссылкой на архив с исходниками и бинарником:
http://www.compression.ru/forum/messages/1459.htm
http://falinc.narod.ru/Stuns.rar

Так вот, обработав битый файл, все неповрежденные потоки были распакованы, но никакая часть content.xml распакована не была.

Более того, если в исправном файле с заведомо большим content.xml испортить хотя бы первый байт сжатого потока, то распаковать из этого потока уже ничего невозможно.

Вот такое неутешительное резюме по результатам сделанных наблюдений.

[kompilainenn]

Вот такое неутешительное резюме по результатам сделанных наблюдений.

предположить причину порчи файла можно?

[bormant]

kompilainenn,
теоретически, ничто этому не мешает, уж очень размер специфический -- ровно 32 КБ или 8 страниц по 4 КБ.
Причём, ZIP архив с документом изначально формируется целиком и как следует, об этом свидетельствует вполне корректное оглавление в конце архива.
Но потом где-то что-то идет не так, и 32 КБ от начала очищаются.
Либо где-то есть буфер на 32 К, но при редких обстоятельствах первым в файл пишется в файл не тот буфер.
Либо еще что-то...

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