Проверить содержимое файла на наличие повреждений, размер файла указывает на «ноль»

Это задокументировано в документации let , прямо под тем местом, где говорится, что он принимает выражение.

let выражение [выражение…]

Встроенная функция let позволяет выполнять арифметические действия с переменными оболочки. Каждое выражение оценивается в соответствии с правилами, приведенными ниже в Арифметика оболочки . Если последнее выражение дает результат 0, let возвращает 1; в противном случае возвращается 0.

Арифметика оболочки включает операторы присваивания = , * = , / = , % = , + = , - = , , >> = , & = , ^ = и | = . Это, как правило, не связано с обычными операторами присваивания, которые не применяют никакой дополнительной обработки.

3
15.11.2016, 22:38
3 ответа

и не показывать содержимое при размещении файла в каталоге.

Отсутствие вывода cat для файла не означает, что файл пуст, как показывает следующий эксперимент:

$ truncate -s 1M foo    
$ ll foo
-rw-r----- 1 user users 1048576 Nov 15 19:28 foo
$ file foo
foo: data
$ cat foo
$ 

cat действительно выводит NUL-символов на 1 МБ, но эти символы случаются быть невидимым в терминале.

Ваш вопрос о пустых файлах несколько неоднозначен. Подходит ли foo выше? Если «пустой» означает нулевую длину, тогда find может вам помочь:

find dir -type f -empty

перечисляет все файлы нулевой длины в dir . Если ваш find не поддерживает -empty , вы можете использовать вместо него -size 0 .

В сценариях оболочки вы можете использовать выражение -s file , которое истинно, если файл существует и не является пустым. Чтобы проверить, является ли файл пустым (при условии, что он существует), используйте что-то вроде

if [ \! -s file ] ; then ... ; fi

. В качестве альтернативы вы можете использовать stat (1) . Здесь с вариантом GNU:

$ stat --format=%s foo
1048576

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

4
27.01.2020, 21:11

Из ваших подсказок:

  • они имеют размер 0 или отличны от него, как сообщает ls -l
  • , что cat ing их, похоже, ничего не показывает
  • wc -l возвращает 0.

Мы можем сказать:

  • они не содержат символа новой строки ( wc -l подсчитывает символы новой строки)
  • если они содержат какой-либо символ, они невидимы в терминал

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

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

Если поле счетчика блоков в inode также не повреждено, вы можете обнаружить их с помощью (при условии, что GNU find и awk ):

find . -size +0 -printf '%b%p\0' | awk -v RS='\0' '
  /^0/{print substr($0, 2)}'

То есть find файлы, размер которых не равен нулю, но использование диска равно нулю.

4
27.01.2020, 21:11

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

Попробуйте du :

$ truncate -s 4G my4g
$ ls -l my4g
-rw-rw-r-- 1 tange tange 4294967296 Mar  4 15:34 my4g
$ cat my4g
$ du my4g
0       my4g
0
27.01.2020, 21:11

Теги

Похожие вопросы