Как проверить 500 000 файлов word,exel,pdf ,txt что они не битые?

Question

[aleks-th]

Немного сумбурно излагаю, но возникла задача глупая.

Есть файлопомойка, много много файлов огромное дерево каталогов со сложной иерахией, куда юзеры пишут файло лет 10 наверное.
В принципе бекапы файлов есть, все работает.
Где-то всего там лежит гигов 500 всякого.
---
Тут произошел инцидент на днях, пользователь скопировал одну папку саму в себя.
Винда честно ругнулась что все сломает, юзер честно сказал - ломай.
Соотвественно от файлов остались название и нечитаемое содержимое, файл читается но там абракодабра.
Я как обычно когда ломается, из бекапа вытащил эту папку ничего не потерялось, но заставило сильно призадумался.
Заела меня паранойя.
---
Всегда проверяли выборочно архив путем развертывания и проверки что файлы есть и читаются.
Естественно выборочно, так как 500000 файлов никто проверить в здравом уме не сможет.
---
Но в данном случае если юзер ничего не скажет, а файло уйдет в архив и условно через полгода, в архивах останутся только битые файлы в какой-то папке которую не заметили и пропустили.
---
Как бы придумать как проверять файлы именно на читаемость содержимого в автомате, чтоб скажем раз в месяц прогонять копию, чтобы проверить открываются эти файлы или нет.

Comments

[xotkot]

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

файл читается но там абракодабра

я так понимаю что пользователь/и имеют полный доступ к базе, а это значит что документы могут быть в любой момент произвольно изменены, то есть, открытие файла и/или наличие в нём абракадабры это пол беды которая сразу укажет на проблему, а вот если там будет читаемая но немного искаженная информация ? возможно в таком случае стоит ввести какое либо версионирование содержимого

[aleks-th]

xotkot,
---
менять документы маловероятно что кто-то будет, выгоду он от этого не получит.
Смысла как бы нет .
Есть документ ворд, есть pdf на случай если ворд сохранят с другими данными.
Есть переписка с клиентом где идет обмен этими доками.
Есть бумажная копия - в двух разных местах - в архиве и у клиента в конце концов.
И главный документ как раз бумажная копия с подписями и печатями в архиве.
---
А доки в базе, как бы на основе них генерируют новые доки в основном.
Как только документ подписал клиент, и бумажная копия положилась в архив , этот файл становится неактуальным, архивным и что-то с ним делать - нет смысла.

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

[swoopspb]

"Как только документ подписал клиент, и бумажная копия положилась в архив , этот файл становится неактуальным, архивным"
Ну так и оставьте пользователям доступ только на чтение

[aleks-th]

swoopspb, если бы сложное наследие решилось таким простым способом.
А об этом долго думал, пришел к выводу что на данном этапе этого не получится.

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

[Денис _______________]

aleks-th,
Для Вашей задачи есть специализированные файловые системы на базе Линукса, та же ZFS и BTRFS
https://ru.wikipedia.org/wiki/ZFS
https://ru.wikipedia.org/wiki/Btrfs
Кроме того для минимизации потерь на серверах рекомендуется использовать ECC память. Вручную можно сравнивать через хэш-суммы, например тот же Total Commander/Double Commander позволяют сосчитать хэши для файлов во всем дереве папок и вывести их в текстовый файл. В notepad++ есть плагин compare, однако есть и другие инструменты, позволяющий(ие) сравнивать содержимое двух файлов между собой.
Так же эту проблему можно решать через бэкапы, через виртуализацию, через БД... т.е. есть множество инструментов. Но, как по мне, смена ОС с windows на linux будет максимально эффективно.

Answer 1

[Zettabyte]

"Новые" офисные форматы (.docx, .xlsx, ...) - это по факту zip-архивы.

Новый (пустой) документ Excel распакуется в виде, ЕМНИП, шести папок и примерно десятка файлов.

Соответственно, их целостность можно проверить с помощью 7-Zip.

Но с .pdf такой фокус не пройдёт.

Текстовые файлы можно проверить с помощью анализа энтропии. Но тут вам потребуется понимание этого дела и, с определённой вероятностью, базовое умение программировать.

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

Когда мне несколько лет назад потребовалась схожая программа, отображающая энтропию, я подходящего ничего не нашёл, в итоге писал не самый прямой костыль сам.

Answer 2

[mayton2019]

Я-бы поделил файлы word,exel,pdf ,txt на группы.

1) Aрхивы docx, xlsx. Как выше заметил один джентльмен их можно проверить любой
утилитой которая умеет читать zip и делать zip -t (test) с выводом статуса в errorlevel.
Автоматизировать можно либо bash либо python скриптом.

Если архив целый (контрольные суммы совпали) то и документ почти 100% не поврежден.

2) Офисные документы старого формата (doc/xls). Здесь я-бы парсил их через apache POI
(это java библиотека). Это разработка. Но простая. На 1 story point. Я думаю
любой первокурсник напишет.

3) Adobe документы. Масса вариантов. Есть автоматизация с помощью bash/python
и консольными тулзами. Я перечислю тулзы которые есть под линукс и которые читают
pdf.

- pdfimages
- pdfextract
- pdftoppm

Напомню что почти все они должны в случае неуспеха генерировать статус код не нулевой.
Это будет критерий проверки.

4) Прочие текстовые документы. Неструктурированные. Я тут честно не знаю как их проверять.
Но допустим если они содержат текст в кодировке win-1251 то любой криптохакер
с cryptohack вам быстро напишет скриптик для проверки что гистограмма или биграмма
соотвествует примерно тексту и национальным признакам. Если файл будет в нулях
или в рандомном шуме то какой-то критерий не сработает. Здесь надо подумать
и просто глазами посмотреть на эти документы. Возможно большая часть из них
это бланки - и тогда надо чекать наличие просто каких-то шаблонов.

Comments

[Adamos]

DOC/XLS можно так же, из командной строки, скармливать LibreOffice с опциями "сконвертировать в ODF", например.
Для текстовых, если там реально cp1251, достаточно iconv, который ругнется на не текстовые символы в тексте. А определить, не осталась ли от "Войны и Мира" только первая глава, автоматически все равно невозможно. Тем более, что она-то как раз в cp1252 :)
В общем, можно обойтись без программирования вовсе.
А утилиты pdf* просто вызывают GhostScript с нужными ключами, можно поизучать его и найти проверяющую команду полегче, чем занимающие немало времени конвертации.

[mayton2019]

Adamos, напишите в ответы. Это вполне хорошие советы автору.

Answer 3

[rPman]

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

Так же можно делать все то же самое из любого другого языка программирования, я помню делал что то похожее на c# в visual studio, это удобнее чем писать на vbscript.
https://learn.microsoft.com/ru-ru/dotnet/csharp/ad...

Comments

[aleks-th]

Направление понял, посмотрю, спасибо за наводку.
В принципе vbscript когда то использовал, простой скрипт написать осилю.

[Adamos]

aleks-th, это направление в никуда и дичайший оверхед.
Все проверяется системными скриптами из командной строки.
Офисные форматы тестируются архиватором, PDF - ghostscript'ом, текстовые - ну, iconv, например.

Answer 4

[kisskin]

у doc/xls есть стандартный заголовок. Его наличие не гарантирует, что остальное целое, но с вероятностью 1E+12
гарантирует что там был офисный документ.

у pdf тоже есть и заговолок и маркер конца.

Тектстовые файлы проверять на попадание в диапазон текстовых и т.п. символов. Либо на отсутствие непечатных символов. Можно регистры текста проверять, но тут будет немало ложных срабатываний.

Такие варианты проверок будут самыми быстрыми, но софт придется самому делать, хотя тут делов на один вечер.

Comments

[shurshur]

В UNIX-системах давным-давно есть утилита file, которая на основе библиотеки libmagic умеет по началу файла определять его тип. У неё большая база сигнатур, помогает при массовом разборе файлов. Например, я однажды разбирал lost+found, в который неудачно улетели сотни файлов, по сигнатурам разделил по каталогам и дальше уже думал как разбираться с контентом разных типов файлов.

Answer 5

[swoopspb]

Самый простой и универсальный для всех типов файлов способ - ежедневно/еженедельно сверять контрольную сумму и сигнализировать если она изменилась.
Ещё можно играться с архивным атрибутом файлов.
Всё это гораздо менее ресурсозатратно чем тестировать каждый документ архиватором.
Да, на абракадабру не проверит, но это можно сделать вторым этапом

Comments

[aleks-th]

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

Если бы они были неизменные я бы им на папки права дал readonly и проблемы бы просто не стало.

Хотя кстати PDF можно выделить и считать у них контрольную сумму, а вот во всякие доки и тексты надо лезть будет.

[mxelgin]

aleks-th, Если редактируются значит рабочие. вам надо не рабочие так сверяйтесь по контрольной сумме. Все что надо знать время инцидента

[kisskin]

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

[swoopspb]

kisskin, вообще не затратно просто проверять архивный атритут файлов :)

Answer 6

[Пума Тайланд]

Нет смысла возиться, сделай слепок текущий рабочий и забейте, если надо вернётесь к нему он никуда не денется

Answer 7

[Be Joy]

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