☰

Не можете найти способ поиска файлов, содержащих 100% значений NULL?

tag-icon • tag-icon windows search
Не можете найти способ поиска файлов, содержащих 100% значений NULL?

Я потерял папку «Рабочий стол» (там у меня было много всего... может быть, 1000 файлов). И сразу же воспользовался инструментом для восстановления удаленных файлов. Он нашел все удаленные файлы и восстановил их. Все они выглядели нормально, что касается дат, размеров и т. д. Итак, я скопировал их обратно в папку «Рабочий стол», только чтобы обнаружить, что каждый из них был на 100% пустым. Я не думаю, что у них вообще есть возвраты каретки. Просто одна длинная строка пустых символов. Хотя файлы имеют правильный размер. Так что...

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

Но теперь у меня 20% файлов, заполненных NULL-значениями, разбросанными по всему рабочему столу и папкам на рабочем столе.

Я не знаю Python и не могу найти инструмент для идентификации этих файлов. Мне кажется безумием, что никто не создал инструмент, который может найти файл, полный 100% символов NUL 00??? Мне сейчас 61 год, и я на пенсии, но я был разработчиком программного обеспечения и не хочу изучать язык только для этого.. Это кажется возможностью для кого-то создать инструмент для обмена. Я пробовал grepWin, используя поиск по регулярным выражениям, и искал везде, но я нашел много людей, пытающихся сделать то же самое и терпящих неудачу..

У меня есть несколько образцов NUL-файлов для тестирования. Я не вижу способа загрузить их сюда..

решение1

Спасибо, Пол. По какой-то причине я не могу прокомментировать ваш ответ. Там написано, что "для комментирования нужно иметь 50 репутации". Может быть, потому, что мой вопрос был перенесен с форумов Unix? IDK..

Ваш ответ — это команда grep? Если так, то мне также нужны некоторые основные указания по этому поводу. Я искал и искал, и пробовал grepWin (который я не могу заставить найти 100% пустые файлы), и скачал grep3.4 (но ни одна команда не работает? Может быть, ему нужна настройка System Path?, IDK), и нашел GnuWin (который, как я думаю, не то, что мне нужно, так как, похоже, он только для 32-битных систем, а у меня Win 10 64)... Я также искал руководства для начинающих, но ни одно из них не показало, как просто настроить Grep для работы.. Они все начинают показывать вам основные команды...

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

решение2

Извините за задержку — я не получил уведомление о вашем ответе, поскольку оставил комментарий как гость.

Это проверенный сценарий, который может потребовать небольшой адаптации.

#! /bin/bash

    find 2>/dev/null . -type f -size +0c | while IFS= read -r fn; do
        NN="$( head --bytes=128 "${fn}" | tr -d '\0' | wc -c )"
        (( NN > 0 )) && continue

        NN="$( tr -d '\0' < "${fn}" | wc -c )"
        (( NN > 0 )) && continue

        printf "rm -f '%s'\n" "${fn}"
    done

Как написано, он создает список команд для удаления всех файлов в дереве каталогов, которые полностью являются символами NUL. Вы можете перенаправить этот список в файл, чтобы проверить его, а затем просто bash < myRmFile. Или вы можете просто поставить | bashсразу после done.

Внешний цикл find ...; do ... doneищет каталог рекурсивно, откуда вы его запускаете. Параметры поиска выбирают только обычные файлы размером не менее одного байта, а затем мы считываем имена в переменную fn по одному за раз.

Следующие две строки — это предварительная проверка оптимизатора, чтобы не читать весь файл. Он проверяет только первые 128 байт, потому что ни один приличный файл не будет иметь 128 байт NUL, а затем что-то еще позже.

Итак, мы назначаем счетчик NN из конвейера из трех команд. NN headвыбирает первые 128 байт, NN trудаляет все NUL, а NN wc -cподсчитывает то, что осталось. Если остались какие-либо не-NUL байты, мы продолжаем со следующим именем файла.

Следующие две строки делают то же самое, но для всего файла, на случай, если мы наткнемся на «непригодный» файл.

Если обе проверки не пройдены, для этого файла генерируется инструкция rm.

Это немного ненадежно для некоторых экстремальных имен файлов — тех, которые содержат одинарные кавычки или символы новой строки в имени. И он запускает процесс rm для каждого файла, но у вас, похоже, их всего около 200, так что это не критично.

Если у вас возникнут проблемы, напишите еще раз.

Связанный контент