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

, в структурах типа , выровненных по 4-х байтной границе.

Рис. 8.12. Хранение имен файлов и каталогов

Структура

определена в файле /src/ufs/ufs/dir.h (листинг 8.11) и содержит: номер inode, описывающий данный файл, тип файла, его имя, а также длину самой структуры , используемую для нахождения следующей структуры этого типа в блоке.

Листинг 8.11. Структура

, отвечающая за хранение имен файлов и каталогов

На этом описание файловой системы UFS можно считать законченным. Для ручного восстановления данных приведенной информации вполне достаточно.

При удалении файла на разделе UFS происходят следующие события (они перечислены в порядке расположения соответствующих структур в разделе и могут не совпадать с порядком их возникновения).

□ В суперблоке обновляется поле

(время последнего доступа к разделу).

□ В суперблоке обновляется структура

(количество свободных inode и блоков данных в разделе).

□ В группе цилиндров обновляются карты занятых inode и блоков данных. Inode и все блоки данных удаляемого файла помечаются как освобожденные.

□ В inode родительского каталога обновляются поля времени последнего доступа и времени последней модификации.

□ В inode родительского каталога обновляется поле времени последнего изменения inode.

□ В inode удаляемого файла обнуляются поля

(IFMT, права доступа), (количество ссылок на файл) и (размер файла).

□ В inode удаляемого файла затираются нулями поля

(массив указателей на 12 первых блоков файла) и (указатель на блок косвенной адресации).

□ В inode удаляемого файла обновляются поля времени последней модификации и последнего изменения inode, время последнего доступа при этом остается неизменным.

□ В inode удаляемого файла обновляется поле

. В исходных текстах оно помечено как зарезервированное, но просмотр дампа показывает, что это не так. Судя по всему, здесь хранится нечто вроде последовательности обновления (update sequence), используемой для контроля целостности inode. Однако это только мое предположение.

□ В каталоге удаленного файла размер предшествующей структуры

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

Обнаружив, что один или несколько файлов были непреднамеренного удалены, немедленно демонтируйте раздел и запустите дисковый редактор, работающий на секторном уровне. Например, можно воспользоваться вариантом уже описанного редактора lde, переписанным для BSD. К сожалению, в моей системе (4.5 BSD) он работает крайне нестабильно. Так, например, он не отображает основные структуры данных в удобочитаемом виде, хотя поддержка UFS в нем заявлена. При наличии достаточного количества свободного дискового пространства можно скопировать раздел в файл и натравить на него любой hex-редактор (например, BIEW). Как вариант, можно открыть непосредственно само устройство раздела (например,

). Наконец, можно загрузить компьютер с загрузочного CD с Windows РЕ и воспользоваться любым Windows-редактором — от Microsoft Disk Probe до Runtime DiskExplorer. Можно загрузиться даже с загрузочной дискеты MS-DOS и запустить Norton Disk Editor (правда, Norton Disk Editor не поддерживает ни диски большого объема, ни устройства SCSI). Наконец, можно запустить KNOPPIX или любой дистрибутив Live Linux, ориентированный на восстановление данных. Правда, в большинстве "реанимационных" дистрибутивов, в частности, Frenzy 0.3, никакого дискового редактора вообще нет.