Как исправить флешку линукс

Программный ремонт USB flash в Linux

Поводом для написания статьи послужило обилие на различных форумах советов по устранению программных глюков флешек с помощью различных утилит «низкоуровневого форматирования» и пр. Не отрицая существования утилит «от производителя», хочу заметить, что существует весьма простой и вполне надежный метод удаления софт-бэдов на флешках, устранения проблем с файловой системой, бутсектором и MBR, возникающих, как правило, при небезопасном извлечении этих устройств из компьютера, либо же из-за иных программных или аппаратных сбоев компьютера (одни только глючные южные мосты ICH5 от Intel чего стоят).

Существующие методы «излечения» этих болезней под ОС Microsoft Windows имеют ряд существенных недостатков, причиной которых является отсутствие в Windows достаточно функциональных средств дискменеджмента даже от сторонних производителей. Простой пример: после «заливки» флешки нулями, Windows форматирует её как super-floppy, т. е. без организации MBR, что для корректной работы флешки под разными ОС недопустимо. Сторонние дискменеджеры либо не умеют работать с USB-устройствами (Norton Partition Magic), либо работают некорректно (Paragon Partition Manager). Работа же с флешкой под различными ОС ведется именно как с жестким диском, поэтому и предъявляемые требования к организации логической структуры аналогичны винчестеру, а не дискете. Для этих целей воспользуемся правильной ОС и правильным софтом, который, как оказалось, к тому же абсолютно бесплатен, в отличие от недофункциональных платных поделок.

Итак. Имеет место флешка, которая либо виснет в Windows, либо просится быть отформатированной, но не форматируется («Виндовз не может завершить форматирование», о, ужас!), либо сыплет бэдами при сканировании тем же HDDScan’ом.

Лично мной работа велась под локализованным неофициальным портом Slackware для 64-битных процессоров BlueWhite64

Подключаем флешку, смотрим список USB-устройств. Вводим lsusb, нажимаем Enter, смотрим вывод:

# lsusb
#Наблюдаем вывод: вот она, родимая, даже, вроде «аппаратно» живая.
Bus 005 Device 003: ID 0ea0:2168 Ours Technology, Inc. Transcend JetFlash 2.0 / Astone USB Drive
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
#Это сканер, он нам не мешает.
Bus 001 Device 003: ID 04a5:20fc Acer Peripherals Inc. (now BenQ Corp.) Benq 5000
Bus 001 Device 001: ID 0000:0000

# hdparm /dev/sdb

/dev/sdb:
#Защита от записи выключена
readonly = 0 (off)
readahead = 256 (on)
#Транслируемая геометрия соответсвует реальной: 1017856 секторов это

512 МБ
geometry = 1014/17/59, sectors = 1017856, start = 0

Теперь сделаем ей «низкоуровневое форматирование», т. е. забъем всё пространства накопителями нулевыми байтами. Таким образом мы удалим софт-бэды, сотрем ошибочные таблицы FAT, загрузочный сектор, MBR. Внимание! Все оставшиеся данные на флешке будут безвозвратно утеряны!

root@H84_103:

# dd if=/dev/zero of=/dev/sdb
#dd вводили без параметров, теперь он ругается на нехватку места на флешке. И правильно, генератор нулей то у нас безразмерный 🙂
dd: запись в `/dev/sdb’: No space left on device
1017857+0 записей считано
1017856+0 записей написано
скопировано 521142272 байта (521 MB), 144,185 секунд, 3,6 MB/s

Флешка USB 2.0 на 512 МБ стиралась 2,5 минуты
Теперь «по-фирменному» создаём раздел.

# mkdosfs /dev/sdb1
mkdosfs 2.11 (12 Mar 2005)

Источник

программный ремонт usb flash накопителей в linux

Довольно таки часто занимался программным восстановлением usb flash накопителей на Windows, ну и заинтересовался как можно это реализовать на Linux. Как раз под рукой лежала флэшка JetFlash TS4GJF160 на 4Gb, которая не хотела работать

Так как же боротся с этим?! Весьма просто…

Вставляем usb flash накопитель в компьютер и определяем какое имя ему присваивается При подключении usb flash накопителя к компьютеру, Linux присваивает ему имя типа sdX (первому устройству присваивается sda, второму sdb и так далее. Но чтобы узнать какое имя он ему присвоил наверняка, используем 1 из способов:

Из этого всего нам нужна только 1 строка:

которая и говорит нам что присвоено имя устройству sdc1

Аналогично первой команде ищем среди последних строк:

Имхо самый оптимальный вариант, выведет весь список смонтированных устройств и в самом конце видим следующее:

Думаю тут все понятно, /dev/sdc1 то что нам и нужно

Забиваем usb flash накопитель нулевыми байтами, набирая:

После чего нам выдаст следующее:

На ошибку можете не обращать внимание, мы же не указали необходимый размер

Форматируем usb flash накопитель, командой:

Создаем новый раздел, командой n:

Просматриваем что получилось, командой p:

Так как Linux раздел нам никчему сменим его, командой t:

Смотрим результат, командой p:

Ну и записываем таблицу разделов на usb flash накопитель, командой w:

Форматируем usb flash накопитель, командой:

После форматирования в раздел FAT16, выведет следующее:

Команда для форматирования в FAT32:

После выполнения этих пунктов, в WinXP usb flash накопитель выдал «Диск не отформатирован» и только после того как я отформатировал стандартными средствами Win все заработало

Вот вообщем-то и все… Удачи в восстановлении!)

Для дополнительной информации об устройстве, введите:

Источник

Как «вылечить» поврежденный USB-накопитель в Linux?

Флэшки есть у всех. Маленькие, удобные – что может быть лучше для сохранения данных. Но бывает, что флэшки повреждаются или вообще отказываются работать. Если вы пользователь Linux и подобное случилось с вами, исправить все будет несложно.

Примечание: описанные методы работают не только для USB-накопителей, но и для жестких дисков тоже.

Интересно: Как отформатировать защищенную от записи флешку. Читаем здесь.

Удаление бэд-блоков с USB-накопитель с помощью fsck

Простой способ починить флэш-накопитель (и вообще любой накопитель) – инструмент fsck. Он удаляет поврежденные сектора, или «бэд-блоки», из-за которых чаще всего и возникают проблемы с чтением. Чтобы удалить поврежденные сектора с флэшки, откройте терминальное окно и введите следующие команды.

Сначала нужно узнать метки дисков. Сделайте это, введя команду lsblk. Появится список всех подключенных накопителей.

Примечание: по команде lsblk появляется список всех дисков, не только USB-накопителей. Будьте внимательны, чтобы не перепутать флэшку с жестким диском.

Чтобы удалить бэд-блок, запустите команду fsck либо в отдельном разделе (например, /dev/sdc1), либо на всем диске (например, /dev/sdc). По окончании процесса ваша флэшка будет снова полностью работоспособна в Linux.

sudo fsck /dev/sdc1

Примечание: здесь предполагается, что метка флэш-накопителя — /dev/sdc (или /dev/sdc1). У разных пользователей метки могут быть другими.

Полная очистка

Иногда USB-накопитель совершенно не читается, и спасти что-то с него уже не получится. Все, что остается в этой ситуации – очистить все данные и начать сначала. Лучший инструмент для этого – dd.

Возьмите метку накопителя, которую вы нашли прежде командой lsblk, и дальше действуйте по предыдущему алгоритму (/dev/sdc1 – раздел, /dev/sdc – весь диск):

sudo dd if=/dev/zero of=/dev/sdc

Создание новой файловой системы

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

Ext4

NTFS

Заключение

USB-флэшки – полезные девайсы. С ними легко переносить данные с одного компьютера на другой вне зависимости от установленной ОС. Вот почему важно знать, что делать, если флэшка вдруг стала недоступной. К счастью у Linux есть мощные инструменты, способные легко «вылечить» флэш-накопитель.

Источник

Восстановление флешки в Linux

Для многих начинающих пользователей система Linux является непривычной средой, в связи с чем, в зависимости от дистрибутива данной операционной системы, многие функции могут выполняться иначе, нежели в Windows. В частности, при использовании съемных носителей информации возникают нередко вопросы об их подключении, форматировании и восстановлении.

Существует немало способов, как выполнить данные операции с флешкой в системе Linux, но остановимся на самых простых и распространенных.

Форматирование с помощью командной строки

После запуска консоли необходимо прописать следующую команду: «# dmesg | tail», благодаря которой системой определяется имя устройства. В командной строке отобразятся данные, где присвоенное системой имя флешки указано в квадратных скобках – в данном случае [sdb]. Это выглядит следующим образом:

Далее необходимо прописать операцию форматирования, однако пользователю должен быть известен файловый формат, заданный на устройстве – FAT32 или NTFS. Каждый формат имеет собственную команду:

Утилита Palimpsest

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

Программа Gparted

Еще один быстрый и распространенный способ форматирования внешних носителей информации. Чтобы восстановить флешку, достаточно выбрать ее в разделе отображенных в утилите устройств, после чего, кликнув правой кнопкой мыши, нажать в контекстном меню на пункт «Форматировать в». Далее необходимо определить нужный файловый формат, после чего начнется процесс восстановления.

Утилита «Управление дисками» (gnome-среда)

Графическая среда Gnome – довольно распространенная оболочка во многих операционных системах Linux. Она отличается большим количеством удобных приложений, инструментов и утилит по управлению системой компьютера, среди которых имеется замечательная программа «Disk Utility» («Дисковая утилита» или «Управление дисками»). Потому, чтобы восстановить флеш-накопитель, достаточно запустить «Диск Утилити», подключить устройство к компьютеру и проделать следующие действия:

1. Выбрать устройство в специальном поле устройств слева, затем нажать кнопку «Настройки» (иконка с шестеренками).

2. Далее в открывшейся вкладке с пунктами выбрать первый «Форматировать раздел…».

3. Затем задать необходимые параметры: ввести любое имя для тома и определить тип файловой системы. После чего кликнуть по кнопке «Далее» и начать операцию восстановления.

Заключение

Перечисленные в статье способы восстановления могут отлично применяться по разным причинам:

Перед тем как проводить форматирование устройства, обязательно удостоверьтесь, что на флешке нет важных для вас файлов. В противном случае, вы рискуете потерять все записанные ранее данные. Ну а если вам необходимо восстановить файлы, то это можно сделать с помощью других специальных программ: TestDisk, Extundelete, R-Studio, R-Linux, DMDE, Foremost, Mondo Rescue и т. д.

Источник

Как восстановить данные с флешки при помощи инструментов Linux.

Сбой с данными всегда проблема. Но если это критически важные данные которые находятся как всегда на флешке, это вдвое большая проблема. Сегодня мы рассмотрим не типичный случай восстановления данных с такого носителя. Как восстановить данные с флешки при помощи инструментов Linux таких как TestDisk, PhotoRec мы рассмотрим в данной статье.

Недавно ко мне пришел товарищ с фразой: «У меня флешка сломалась, можешь посмотреть? В принципе, если не получится, то и ладно, но там есть несколько файлов, копий которых нет».

Я, конечно, флешку взял и обещал посмотреть, что можно сделать. Грех не помочь другу! Входные данные были такие: «винда перестала видеть флешку». Других внятных объяснений произошедшего я не добился.

И вот, когда выдалось немного свободного времени, настала пора попробовать восстановить какие-то данные с флешки.

В этой статье рассматривается восстановление флешек в среде Linux. В Windows тоже можно восстанавливать данные: есть разные утилиты и проприетарные продукты (например, R-Studio), но это тема для отдельных статей.

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

Второе, что я сделал, — снял образ.

Техника безопасности: снимаем образ

Самая важная часть в восстановлении данных — не угробить своими действиями еще больше данных. Все описываемые в статье действия производились исключительно с образом флешки. Снять образ можно следующими командами (тебе, конечно, надо указать путь к своему устройству):

Как вариант, можно использовать команду ddrescue:

Лично я предпочитаю второй способ, поскольку ddrescue пытается считать данные в несколько проходов, а также (если ты дал команду писать лог) прервать чтение и продолжить с места остановки. Плюс к этому утилита дает красивый отчет о том, сколько данных считалось, а сколько нет, и оценку времени до конца съема образа.

Кроме того, имеет смысл работать с копией образа. Вдруг ты его испортишь, и не факт, что получится еще раз снять образ с флешки, если она умирает из-за аппаратных проблем. Для частичных копий образа и восстановления испорченных частей к начальному состоянию рекомендую пользоваться тем же всемогущим dd.

Параметр notrunc нужен для того, чтобы dd не обрезала файл-назначение, когда закончатся данные в файле-источнике.

Сняв образ флешки, я взглянул на содержимое. Увиденное несколько меня удивило.

00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |…………….| * 00400000 01 76 0a 00 02 76 0a 00 03 76 0a 00 04 76 0a 00 |.v…v…v…v..| 00400010 05 76 0a 00 06 76 0a 00 07 76 0a 00 08 76 0a 00 |.v…v…v…v..| 00400020 09 76 0a 00 0a 76 0a 00 0b 76 0a 00 0c 76 0a 00 |.v…v…v…v..| 00400030 0d 76 0a 00 0e 76 0a 00 0f 76 0a 00 10 76 0a 00 |.v…v…v…v..| 00400040 11 76 0a 00 12 76 0a 00 13 76 0a 00 14 76 0a 00 |.v…v…v…v..| …

В образе первые 4 Мбайт данных были забиты 0xFF. Поврежден блок флеш-памяти? Чья-то попытка стереть данные? Сбой какого-то приложения? Почему затерта область — неважно. Главное, что у нас нет ни таблицы разделов, ни структуры файловой системы… Хотя если приглядеться, то видна закономерность. Перед нами последовательность увеличивающихся на единицу 32-битных чисел (в формате LittleEndian): 0x000a7601, 0x000a7602, 0x000a7603… Следовательно, у нас на флешке, скорее всего, была файловая система FAT32.

Что ж, попробуем восстановить данные. Для начала возьмем утилиту TestDisk.

TestDisk

TestDisk — не просто утилита, а мощный комбайн по восстановлению данных.

О TestDisk

TestDisk разработан Кристофом Гренье и распространяется по лицензии GPL v2. Эта утилита предназначена в первую очередь для восстановления потерянных разделов на носителях информации, а также для восстановления загрузочного сектора.

Запускаем TestDisk такой командой:

Стартовый экран TestDisk

Выбираем пункты меню Procced → Intel → Analyse и получим следующее.

Выбор типа разметки Выбор опций Таблица разделов Еще одна таблица разделов

Видим, что TestDisk не нашел таблицы разделов. Ожидаемо, ведь она затерта. Попробуем ее восстановить с использованием «быстрого поиска» разделов на диске. Выбираем пункт Quick Search.

Все еще без таблицы разделов

TestDisk ничего не нашел, но и это ожидаемо, ведь раздел FAT32 тоже поврежден. TestDisk теперь предлагает нам прописать разделы вручную, но мы не знаем, что где лежало. Поэтому пока отложим эту утилиту в сторону. Для выхода достаточно несколько раз нажать кнопку q.

Что ж, возьмем тогда на вооружение другое изобретение того же автора — PhotoRec.

PhotoRec

PhotoRec — это программа для восстановления утерянных (удаленных) файлов. Изначально она разрабатывалась для восстановления изображений из памяти цифровых камер, отсюда и название — PHOTO RECovery. Со временем она обросла функциями восстановления и других типов данных, но название осталось.

О PhotoRec

PhotoRec ищет известные заголовки файлов. Если нет фрагментации, которая часто бывает, он может восстановить весь файл. PhotoRec распознает многочисленные форматы файлов, включая ZIP, Office, PDF, HTML, JPEG и другие форматы графических файлов. Полный список форматов, поддерживаемых PhotoRec содержит более 390 расширений (около 225 семейств форматов).

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

Натравим эту утилитку на наш образ флешки и посмотрим, что получится.

Стартовый экран PhotoRec

Видим уже знакомый интерфейс, выбираем Proceed → Search → Other, указываем папку, куда сохранять (лучше ее создать заранее), жмем кнопку c. И ждем.

Выбор раздела Выбор типа файловой структуры Выбор папки назначения Процесс восстановления

В итоге получаем несколько папок с тысячами файлов в них.

Куча сохраненных файлов

Беглый осмотр показал, что какие-то файлы восстановились: и документы, и картинки, и исходники. Но нет ни имен файлов, ни даты их создания, ни структуры папок. Кроме того, как оказалось, на флешке была какая-то документация в виде страничек HTML с кучей мелких картинок. В связи с чем поиск ценных файлов занял бы не один час…

Да и, как указано на врезке, фрагментированные файлы или не восстановились, или повреждены (обрезаны).

Видимо, придется напрячь все свои силы и руками восстановить структуру FAT32.

Чиним FAT32

Для восстановления структуры FAT32 надо внимательно почитать документацию, вычислить значения ключевых параметров, а затем внести их в загрузочную запись FAT32. Кратко суть структуры FAT32 изображена на рисунке.

Сюда входит загрузочный сектор, структура FSInfo, две копии таблиц FAT и область данных. Загрузочный сектор (он же BPB — Boot Parameter Block) содержит основные данные, которые описывают характеристики раздела, и код загрузчика.

В таблице FAT хранятся записи номеров следующих кластеров цепочки файла/директории, признак последнего кластера в цепочке (значение 0xFFFFFFFF) или признак свободного кластера (значение 0). Область данных начинается с корневой директории, содержимое дальнейшей области зависит от данных в записях корневой директории и соответствующих цепочках таблицы FAT. Более подробное описание файловой системы смотри по ссылкам, приведенным во врезке.

Для удобной работы с образом нам потребуется Hex-редактор. Лично мне очень нравится редактор 010 Editor. Он позволяет задавать шаблоны структуры на C-подобном языке и подсвечивать поля структуры в редакторе.

Откроем в нем наш образ флешки.

Ищем смещения

Начнем с того, что нам надо вычислить адреса, с которых начинаются раздел FAT32 и первая копия таблицы FAT.

Сначала поймем, повреждена у нас первая копия FAT или обе. Из документации мы знаем, что таблица FAT начинается с последовательности F8 FF FF FF (число 0xFFFFFFF8 в Little Endian). Поищем ее.

Поиск сигнатуры

Нам повезло — такая сигнатура нашлась. Значит, повреждена только первая копия таблицы FAT и мы можем скопировать данные второй таблицы в первую. Конечно, стоит помнить, что если флешка была отключена внезапно, то вторая копия может не полностью совпадать с первой (в нее просто не успели сохраниться изменения). Но все же мы сможем восстановить больше данных, чем при помощи только PhotoRec. Как минимум получим дополнительно имена файлов, даты их создания, корректные цепочки для фрагментированных файлов и даже структуру директорий.

Смотрим адрес — 0x8AE400. Это адрес начала второй копии таблицы. Теперь надо вычислить длину самой таблицы. Можно, конечно, руками полистать дамп, пока не заметим данные корневой директории. Но есть вариант попроще. Поскольку это две копии, то и запись, с которой начинается кусок первой копии таблицы, должна быть и во второй копии. А разница между ними и будет размером!

Поищем последовательность 01 76 0A 00, которую мы видели вначале, когда воспользовались hexdump. Быстро начинают находиться варианты. Остановим поиск нажатием ESC — нас интересуют первые два вхождения.

Первое вхождение последовательности

Первое вхождение (адрес 0x400000) — первая уцелевшая запись в первой копии FAT. Перед ней затертое пространство.

Второе вхождение последовательности

Второе вхождение (по адресу 0xB4BC00) — эта же запись во второй копии FAT. Перед ней мы видим сохранившиеся данные цепочек.

Вычислим размер таблицы FAT: 0xB4BC00 – 0x400000 = 0x74BC00 байт. Следовательно, если вычтем этот размер из адреса начала второй копии таблицы, то получим адрес начала первой копии: 0x8AE400 – 0x74BC00 = 0x162800.

Итак, у нас есть смещение начала таблиц FAT. Теперь надо найти адрес начала раздела. Согласно данным в спецификациях и статьях, приведенных во врезке, обычно первая копия таблицы начинается с 32-го сектора. Сектора, напомню, по 512 байт, значит, начало раздела должно находиться по адресу 0x162800 – 32 * 512 = 0x15E800.

Кстати, зная размеры таблиц и смещения их начала, можем найти адрес начала корневой директории.

Смещение корневой директории равно 0x15E800 + 32 * 512 + 2 * 0x74BC00 = 0xFFA000. И начинается она записью Transcend, что, очевидно, является меткой раздела.

Отлично. Смещения таблиц, корневой директории и адрес начала раздела знаем, осталось придумать, что записать в загрузочную запись. Можно сидеть и читать спецификации, высчитывая каждое значение. А я предлагаю сделать ход конем! Создаем пустой файл размером с раздел. Далее мы его форматируем в FAT32. Затем копируем первые 32 сектора в наш образ — и готово! 🙂

Попробуем воплотить этот план в жизнь.

Создаем загрузочную запись

Для начала определим размер раздела.

Размер раздела равен равен размеру флешки минус смещение раздела. Получается 15 676 211 200 – 0x15E800 = 15 674 775 552 байта.

Чтобы не занимать кучу места на диске нашим пустым образом, воспользуемся фишкой файловой системы ext2 — разреженными файлами.

Откроем файл в 010 Editor. И воспользуемся шаблоном Drive (возможно, его потребуется установить, см. меню Templates Repository). Если появится окошко с предупреждением о долгой работе, соглашаемся на продолжение работы скрипта.

Смотрим сгенерированный образ Разбор полей образа Разбор полей BPB

Прекрасно! Теперь у нас есть заполненные структуры загрузочного сектора. Надо бы их перенести в наш образ.

Выделяем мышкой структуру FAT_BOOTSECTOR в окне Templates Results, автоматически выделится диапазон данных, скопируем их в буфер (щелкнуть правой кнопкой мыши в окне данных и выбрать пункт Copy).

Собираем чудовище Франкенштейна

Для сборки образа вставим сгенерированный загрузочный сектор и скопируем вторую копию FAT поверх первой.

Начнем с вставки загрузочного сектора. Он у нас уже в ОЗУ. Перейдем на вычисленный адрес 0x15E800 и вставим данные из буфера.

Вставленные данные

Выясняется, что после сектора идут байты 0xFF, а в сгенерированном образе после этого сектора есть еще данные.

Сгенерированный образ

Непорядок. После первого сектора ведь идет структура FSInfo! Да и по смещению 0xC00 находится копия загрузочного сектора (на случай его повреждения). Нет, лучше скопируем все 32 сектора (0x4000 байт). Кстати, заодно убедились, что в образе, сгенерированном mkfs, по смещению 0x4000 будет последовательность F8 FF FF FF. После вставки в наш образ мы оказались по адресу 0x162800, который ранее и рассчитали. Пока все совпадает.

Теперь нам надо скопировать вторую копию FAT поверх первой. Выделяем участок длиной 0x74BC00 с адреса 0x8AE400, копируем его и вставляем по адресу 0x162800. Для выделения участка удобно воспользоваться фичей Select Range (Ctrl + Shift + A) — просто введем в поля адрес и размер.

Корневая директория

После вставки оказались в начале корневой директории. Пока все сходится.

Теперь нам бы смонтировать этот раздел и посмотреть, что удастся с него считать.

Читаем данные

Для монтирования файловой системы выполним следующие команды.

1’: Ошибка ввода/вывода ls: невозможно получить доступ к ‘mnt/map_n’: Ошибка ввода/вывода 10_10_2016 2019.07.13 28-02-

Потрясающе! Образ примонтировался, и даже есть названия файлов и директорий. Но есть и какие-то странные ошибки. Посмотрим подробнее (часть записей в выводе специально пропущено).

Очень странно. Да и просмотр содержимого директорий дает понять, что где-то закралась ошибка.

$ ls mnt/some_dir/ ls: невозможно получить доступ к ‘mnt/some_dir/%PDF-1.4.’$’n»%╨’: Ошибка ввода/вывода ls: чтение каталога ‘mnt/some_dir/’: Ошибка ввода/вывода

Имя файла совпадает с заголовком PDF. Похоже, кластер, на который указывает запись для этой директории, содержит PDF.

Волшебства не произошло, придется разбираться, в чем косяк. Но перед этим немного упростим себе жизнь и создадим таблицу разделов. Забегая вперед, скажу, что шаблон Drive в редакторе 010 Editor вроде бы шибко умный, но начать разбор с определенного смещения не может, только с начала файла.

Для создания таблицы разделов воспользуемся утилитой fdisk. Создадим один раздел, начинающийся с сектора номер 2804. Смещение нестандартное (по умолчанию — 2048), возможно, что на флешке было два раздела, первый был маленький и погиб целиком. Но это уже неважно. Сам сектор вычисляется легко — просто делим начало смещения раздела на размер сектора (0x15E800/512 = 2804).

Вывод fdisk

Обращаю внимание, что fdisk определил наличие по этому смещению раздела с FAT32 (vfat) и спросил, не удалить ли. Кроме того, не забываем поменять тип раздела на W95 FAT32 (LBA) (код 0c).

Работа над ошибками

Поиск ошибки занял у меня где-то час, в течение которого я активно курил спецификации и сверял значения в структурах, разобранных шаблоном Drive в 010 Editor. Вкратце опишу свои поиски.

Скриншот полей BPB

Сначала я заметил, что корневая директория расположена по адресу 0xFFA800, а не по адресу 0xFFA000.

Я подумал, что неверно определен размер кластера. Утилита mkfs создала кластеры по 16 секторов, а секторы по 512 байт (см. на скриншоте поля BytesPerSector и SectorsPerCluster ). Сначала я попробовал поиграть значениями этих параметров, каждый раз перемонтируя образ.

Или можно еще проще (читай man losetup):

Далее можем монтировать и перемонтировать раздел сколько угодно.

После каждой правки не надо заново подключать loop-устройство, смещение раздела в образе у нас не меняется.

Ничего путного из этого не вышло. Становилось только хуже.

Через некоторое время я понял, что и вторая копия таблицы начинается не там, где надо.

И тут я обратил внимание на поле SectorsPerFat32 (на скриншоте). Это поле описывает размер таблицы FAT в секторах. Его значение равно 0x3A60, а должно оно быть 0x74BC00/512 = 0x3A5E. Разница в два сектора на каждую копию таблицы FAT как раз дает нам 2 * 2 * 0x200 = 0x800 байт разницы между правильным смещением корневой директории и имеющимся у нас ошибочным.

Правим его (прямо в окне структуры, что очень удобно), сохраняем изменения и проверяем.

Отлично! Ошибки пропали! Все файлы и папки читаются. Структура похожа на корректную.

Натравив на образ fsck, все равно видим ворох ошибок. Однако первое, что бросается в глаза, — это несоответствие загрузочных записей.

Что ж, исправим и вторую копию. К сожалению, шаблон 010 Editor не разбирает вторую копию загрузочного сектора, поэтому сами найдем нужный байт и поправим его. Его легко найти — смещение 0x24 от начала сектора, в нашем случае 0x15F424, меняем 0x60 на 0x5E.

Запускаем еще раз fsck.

Странно, но fsck выдает ошибки и говорит, что копии таблиц FAT не совпадают (хотя мы же их копировали), и жалуется на длины файлов. Возможно, повлияли предыдущие монтирования или что-то еще.

Я восстановил из бэкапа (ты же прочел врезку о технике безопасности?) оригинальный образ флешки и заново прошел этапы копирования таблиц, загрузочного сектора (с правкой поля SectorsPerFat32 ) и его копии. Повторный запуск fsck меня порадовал.

Выводы

В заключение, думаю, стоит отметить, что если с ходу утилиты TestDisk и PhotoRec не дают хороших результатов, то не стоит отчаиваться и надо попробовать восстановить данные с флешки с использованием головы и прямых рук. В итоге всей работы, которая суммарно заняла около двух часов, мы восстановили фактически все данные с «умершей» флешки, включая структуру директорий и всю метаинформацию.

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

Источник