Есть ли в Linux не удаляемые файлы?

4

Я никогда не видел этого раньше (20 лет * nix). Я пытался сохранить свой жесткий диск (подробности по запросу) и был довольно успешным, за исключением некоторых файлов, которые выглядят так: 

$ ls -al
$ ?????????? ?    ?       ?      ? blah.txt

На этот файл не влияют команды rm, rm -f, shred, mv, chown, chmod или любые другие команды, которые я могу придумать.

пример 

# whoami
root

# rm -f blah.txt
rm: cannot remove `blah.txt': permission denied

# ls -la blah.txt
?????????? ?    ?       ?      ? blah.txt

В основном то же самое для любых команд в этом файле.

Есть идеи?

unix bev
источник
10
20 лет Unix и вы еще не видели поврежденную файловую систему и / или сломанный HD? Повезло тебе.
Janne Pikkarainen
Ах, я так и думал. Да, наверное, мне так повезло. HD не сломан, кстати. Работает отлично.
bev
Обычно это означает, что имя файла указано в каталоге, но не может получить доступ к его inode. Возможно, в каталоге указан неправильный номер инода, или инод на диске может быть поврежден.
mark4o

Ответы:

1

Можете ли вы показать нам вывод 'lsattr blah.txt'? Это скажет нам, какие специальные флаги этот файл установил.

Можете ли вы также проверить в dmesg (журнал сообщений отладки ядра) что-нибудь новое (запустите dmesg дважды, один раз перед вашими попытками удалить файл, один раз впоследствии и посмотрите, не появилось ли что-нибудь новое внизу журнала).

Пример сообщения о повреждении файловой системы может выглядеть так: 

[86777.332361] EXT4-fs (dm-0): error count: 436
[86777.332365] EXT4-fs (dm-0): initial error at 1290174395: ext4_mb_generate_buddy:726
[86777.332367] EXT4-fs (dm-0): last error at 1292151653: ext4_mb_generate_buddy:726
[86777.332419] EXT4-fs (dm-8): error count: 1406
[86777.332423] EXT4-fs (dm-8): initial error at 1290623933: ext4_mb_generate_buddy:726
[86777.332425] EXT4-fs (dm-8): last error at 1292168399: ext4_mb_generate_buddy:726

и это указывает, что ~ 86777 секунд с момента загрузки (эта часть может не отображаться в вашей системе, это зависит от настроек ядра) было две ошибки, относящиеся к файловой системе EXT4 на моей тестовой машине.

qdot
источник
@qdot, спасибо за совет. Я пока не могу попробовать, потому что попытался устранить проблему. Я «прикоснулся» к файлу (я отказался от восстановления данных), и теперь этот файл выглядит как обычный файл без содержимого. Пока я брожу по своим фс, я уверен, что увижу больше таких (пока 2), после чего я попробую lsattr и опубликую результат.
bev
@qdot - хорошо, вот вывод: lsattr: Операция не поддерживается При чтении флагов на blah.txt. НО, lsattr не возвращает никакой информации для любого файла в моей системе. Там написано: lsattr: неподходящий ioctl для устройства, читая флаги на каждом файле & gt ;. Итак, либо lsattr не работает с reiserfs, либо мой жесткий диск поврежден, но, кажется, работает нормально. Hmmmmm. Глядя на dmesg сейчас.
bev
ReiserFS: предупреждение: is_tree_node: уровень узла 0 не соответствует ожидаемому 1 ReiserFS: sda3: предупреждение: vs-5150: search_by_key: неверный формат найден в блоке 869576. Fsck? ReiserFS: sda3: предупреждение: vs-13070: reiserfs_read_locked_inode: произошла ошибка ввода-вывода при попытке найти данные статистики [265071 265097 0x0 SD] ReiserFS: предупреждение: is_tree_node: уровень узла 0 не соответствует ожидаемому 1 ReiserFS: sda3: предупреждение: vs-5150: search_by_key: неверный формат найден в блоке 869576. Fsck?
bev
Ях. Похоже, есть проблема со структурой inode. Я собираюсь снова запустить fsck.
bev
Запустил fsck --check, который теперь говорит мне, что происходит много коррупции, и мне нужно запустить fsck --rebuild-tree. Итак, сделав резервную копию моего раздела пару дней назад, я запустил его. Я вернусь к вам на результат.
bev
7

Ваша файловая система повреждена. Fsck, скорее всего, поможет.

edit: если вы не используете ReiserFS, в этом случае fsck может повредить его дальше ...

jlliagre
источник
1
Это было первое, что я сделал. Не вернул плохих блоков.
bev
1
Это не может быть ничего другого. Пересмотрите эту возможность. Тем не менее, я только что заметил, что вы используете ReiserFS. Помните, что ReiserFS fsck может просто уничтожить вашу файловую систему. Это один из недостатков дизайна ReiserFS ...
jlliagre
1
Один из недостатков reiserfs в том, что запуск reiserfsck может уничтожить файловую систему? Это полезно знать (после того, как, конечно, я запустил reiserfsck в моей файловой системе), я попытаюсь найти документацию по этому вопросу. К счастью, я все поддержал 2 дня назад. Ох - и ты был прав. Я перезапустил fsck, и это показало мне много проблем.
bev
1
От en.wikipedia.org/wiki/ReiserFS : Процесс восстановления дерева в fsck ReiserFS вызвал много критики: если файловая система настолько сильно повреждена, что ее внутреннее дерево становится непригодным, выполнение операции восстановления дерева может привести к дальнейшему повреждению существующих файлов или появлению новых записей с неожиданным содержимым
jlliagre
@jlligre - спасибо за ссылку. Довольно страшно. Я обдумываю свой следующий шаг. У меня есть резервная копия всего раздела. У меня есть причина полагать, что физический жесткий диск в порядке, текущая ситуация связана с тем, что я перебрал 2 внешних жестких диска после того, как сделал резервное копирование (хотя я не вижу, что я сделал, что вызвало это). Не могли бы вы предложить мне уничтожить раздел и отформатировать в ext3? спасибо за совет.
bev
4

chattr +i file делает файл полностью защищенным от записи, даже root. Это называется неизменным. Чтобы удалить или изменить, сначала нужно сделать его снова изменяемым chattr -i file,

theomega
источник
спасибо за помощь, к сожалению, это не сработало. Вот что произошло: $ & gt; chattr -i blah.txt $ & gt; chattr: Отказано в доступе при попытке получить статистику blah.txt
bev