| vasek |
|
|
Темы:
47
Сообщения:
11743
Участник с: 17 февраля 2013
|
По следам этого топика заинтересовала проблема испорченного файла, который не удаляется. Никогда с таким не сталкивался, проверить лично не могу, но попробую хотя бы описать возможный способ для решения данной проблемы. Кроме того, используя debugfs можно получить много дополнительной информации о файловой системе и, в некоторой степени, даже выполнять определенные изменения. Работу с данной утилитой не описываю, отсылаю к man и DOC, а вот в части применения к данному случаю опишу подробно. .... И да, будте внимательны в режиме внесения изменений - семь раз подумай, один раз отрежь. С данной тематикой немного знаком, а потому видится следующий способ решения проблемы при удалении файла - очистка блока inode - блок обнулится и система должна перестать видеть данный файл. 100% гарнтии нет, НО если даже и не поможет, информация думаю будет полезна. Показывать буду на нормальном файле /home/vasek/TTT/TEST/TEST.txt 1. Разминка - ознакомление, НЕ ОБЯЗАТЕЛЬНОЕ - этого можно ничего и не делать, привожу для понимания. Узнаем номер inode данного файла ls -i /home/vasek/TTT/TEST/TEST.txt 655365 /vasek/TTT/TEST/TEST.txt Иногда это и не получится сделать (как в случае указанного выше топика), тогда используем следующую команду sudo debugfs -R 'imap /home/vasek/TTT/TEST/TEST.txt' /dev/sda3 И так, строчка located at block 2621472, offset 0x0400 несет информацию о расположении блока inode на разделе, точнее показывает смещение от начала раздела. Зная это и выполнив соответствующий расчет (от начала раздела sda3 = 2621472 * 4096 + 1024 = 10737550336 ) вытаскиваем этот блок с диска sudo hexdump -C -s 10737550336 -n 256 /dev/sda3 stat -c%x /home/vasek/TTT/TEST/TEST.txt 2020-02-17 20:50:20.057984051 +0300 Если полностью очисть этот блок (точнее 128 байт), то файл исчезнет - система о нем знать не будет - это можно проделать как в ручную (самый надежный способ), так и с помощью утилиты debugfs, но вот всегда ли это сработает, практически 100% уверенности нет, но теоретически должно сработать. 2. Процесс очистки inode с использованием debugfs В linux есть очень хорошая утилита debugfs, с ее помощью можно очень многое проделать, в ней действуют все те же команды, что и в обычном bash (ls, cat, stat, rm и др.) плюс к этому можно вытащить очень много полезной информации, вплоть до удаленных файлов. Но редко кто пользуется этим - все привыкли к GUI. В работающей системе утилита запускается в режиме read only и можно только просматривать информацию, а вот менять не возможно. Для этого нужно перевести систему в режим записи и лучше отмонтировать. А так как нам нужно будет вносить изменения, то буду грузиться с Live CD … я могу загрузиться и с образа archiso, расположенного на диске, в этом же разделе, НО лучше оставить раздел, с которым будем работать, в покое, а потому загружусь с флешки, на которой несколько образов, но я для удобства выберу systemrescuecd-6.0.0 (нужно будет копировать команды и их вывод в файл и сохранить все это на флэшке). PS - чем мне нравится systemrescuecd-6.0.0 - он сделан на основе ArchLinux, а если запустить startx, то попадаешь в DE xfce - очень удобно. И так приступим, загрузились и запускаем debugfs, конечно, перед началом рекомендую уточнить разделы утилитой fdisk или альтернативной командой sudo debugfs /dev/sda3 debugfs: ... получаем строку приглашения для ввода команд и смотрим наш файл в нужной директории ... debugfs: ls -l /home/vasek/TTT/TEST ……. 655365 100644 (1) 1000 100 6 17-Feb-2020 20:50 inode …… номер inode 655365 совпадает с приведенным в начале ... то есть можно было его и не узнавать перед этим, но так спокойнее - лишняя проверка не помешает Посмотрим информацию из блока inode (hex вывод блока inode был приведен выше) debugfs: mi <655365> mi: Filesystem opened read/only … нам напоминают, что система только для чтения - переведем в режим записи debugfs: open /dev/sda3 -w open: Filesystem /dev/sda3 is still open. Close it first. … говорят, что сначала закройте … закроем и снова откроем (обычно на этом большинство спотыкается) debugfs: close_filesys -a debugfs: open /dev/sda3 -w debugfs: … все нормально - ожидание для ввода команд - посмотрим инфу inode debugfs: mi <655365> … для листания Enter, для выхода q ... Приступим к очистке inode debugfs: clri <655365> и снова смотрим информацию inode debugfs: mi <655365> 3. Загрузка после проведенных работ. По идее нужно сразу при загрузке выполнить проверку fsck -fv /dev/sda3, зарузившись с параметром break или break=premount … количество свободных inode изменилось, да и кое что еще во внутренностях ext4 изменилось - пусть система все проверит, изменит и запишет …. но мы сейчас этого не делали - интересно посмотреть сразу же (до проверки), до всяких изменений, как будет выглядеть блок inode. И так, загрузились успешно, смотрим этот файл ls /home/vasek/TTT/TEST/TEST.txt sudo hexdump -C -s 10737550336 -n 256 /dev/sda3 И все таки я перегружусь и сделаю проверку fsck …. перегрузился, проверился, но проверка выполнилась автоматом, сама - но я все равно запустил повторно Загрузились, проверяем повторно ls /home/vasek/TTT/TEST/TEST.txt sudo hexdump -C -s 10737550336 -n 256 /dev/sda3 Как то так, может кому и пригодится - не обязательно для этих целей, но возможно для … не хороших дел (например, изменения даты) … или получения дополнительной информации. EDIT 1 - Уточнение, разумеется, если уж заупрямится обнулить debugfs, то это всегда можно выполнить в ручную, прямо на диске ... EDIT 2 - .... и еще раз напоминаю, в режиме write, будте внимательны и осторожны - You may completely destroy the data on your hard disk!
Ошибки не исчезают с опытом - они просто умнеют
|