У меня довольно известная проблема, но, к сожалению, мне немного не хватает знаний в этой области, и я надеюсь найти здесь более подробную информацию.
Итак, у меня есть поврежденная USB-флешка с файловой системой FAT32. Я сделал клон с помощью ddrescueи запустил testdisk. Раздел был найден (уф!), поэтому я создал петлевое устройство с помощью losetup -f -P USB_clone.imgи смонтировал его. Пока все хорошо, теперь начинается проблема: все файлы найдены с, как мне кажется, правильным размером ( ls -al), но когда я попытался скопировать файл, я получил ошибку ввода-вывода. Поэтому я снова размонтировал раздел и запустил dosfsck -l -r -v /dev/loop1p1. Некоторые файлы удалось восстановить, но большинство файлов были восстановлены довольно интересным способом:
File size is 27589006 bytes, cluster chain length is 32768 bytes.
Truncating file to 32768 bytes.
В результате получаются обрезанные файлы; это, очевидно, не то, что мне нужно...
Итак, это подводит меня к нескольким вопросам:
Что здесь происходит? Кажется, что размеры файлов можно определить правильно, но что-то совсем не так в, хм, ну, в чем? Может быть, таблица разделов? Почему
dosfsckне получается это исправить, когда имя файла и размер файла можно определить правильно?И, конечно, что еще важнее: есть ли способ восстановить эти файлы?
Если вам нужна дополнительная информация, просто запросите ее!
Большое спасибо!
решение1
Хорошее объяснение фрагментации файловой системы FAT можно найти здесь:Quora: Как операционная система обрабатывает фрагментированные сектора в формате FAT32 для восстановления полных данных?Ирене Барнард.
У каждого сектора есть часть сзади (или спереди, какова бы ни была детальная конструкция, но где-то внутри этого сектора)… что-то, что гласит «следующий сектор в позиции X». Это заложено в конструкции всех файловых систем на основе FAT, включая FAT32. И это также причина, по которой фрагментация замедляет доступ к файлам на FAT.
Вот как это работает:
- Вы (или какая-либо запущенная вами программа) отправляете операционной системе запрос на открытие файла.
- Операционная система передает запрос файловой системе.
- ФС (FAT) проверяет путь + имя файла, находя первую папку по указанному пути.
- Затем он считывает таблицу корневых папок (т.е. начало иерархии папок диска). Это дает ему номер сектора для первой папки в пути.
- Затем он продолжает читать таблицу этой папки, сопоставляя ее со следующей папкой в указанном пути. Повторяя, пока не будет найдено последнее имя файла/папки в пути.
- Это даст ему информацию о секторе, в котором начинается файл, а также о размере файла, чтобы он знал, когда будут найдены все его сектора (простое сложение размеров секторов).
- Он считывает первый сектор, проверяя его метаданные (т.е. указатель на следующий сектор).
- Читает и его, добавляет размер данных сектора к уже прочитанному количеству. Если все еще меньше размера файла, переходит к следующему сектору в метаданных и повторяет.
Суть в том, что файлы, которые усекаются, вероятно, фрагментированы. Когда программа восстановления проходит по блокам и пытается найти следующий фрагмент, она решает не доверять тому, где, по ее мнению, находится следующий блок.
Правила и проблемы, которые dosfsckиспользуются для сравнения и принятия решения о том, когда следует усекать, приведены ниже.https://linux.die.net/man/8/dosfsckи трудно понять, почему он усекается, не зная, какой ущерб был нанесен диску изначально. Если FAT был стерт, то может быть, что он не считает, что какой-либо из кластеров, перечисленных в цепочке кластеров, используется, и вы попадаете в правилоFile contains bad or free clusters. The file is truncated.
dosfsckне является средством восстановления. Это средство ремонта, которое изначально предполагает, что диск в целом «в порядке».
Возможно, вам стоит рассмотреть возможность использования надлежащих инструментов восстановления, таких какphotorec который может восстановить гораздо больше, чем просто фотографииили testdiskчто может сделатьгораздо больше, чем просто копирование разделов.