Восстановление данных. Практическое руководство

/* 0x48 */ int32_t      di_ctimensec;    /*  72: Время последнего доступа */

/* 0x4C */ int32_t      di_birthnsec;    /*  76: Время создания Inode */

/* 0x50 */ int32_t      di_gen;          /*  80: Номер генерации */

/* 0x54 */ u_int32_t    di_kernflags;    /*  84: Флаги ядра */

/* 0x58 */ u_int32_t    di_flags;        /*  88: Флаги статуса (chflags) */

/* 0x5C */ int32_t      di_extsize;      /*  92: Блок внешних атрибутов */

/* 0x60 */ ufs2_daddr_t di_extb[NXADDR]; /*  96: Блок внешних атрибутов */

/* 0x70 */ ufs2_daddr_t di_db[NDADDR];   /* 112: Непоср. дисковые блоки */

/* 0xD0 */ ufs2_daddr_t di_ib[NIADDR];   /* 208: Косв. дисковые блоки */

/* 0xE8 */ int64_t      di_spare[3];     /* 232: Зарезервировано */

};

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

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

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

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

Листинг 8.11. Структура direct, отвечающая за хранение имен файлов и каталогов

struct direct {

/* 0x00 */ u_int32_t d_ino;                 /* Номер inode данной записи */

/* 0x04 */ u_int16_t d_reclen;              /* Длина данной записи */

/* 0x06 */ u_int8_t  d_type;                /* Тип файла, см. ниже */

/* 0x07 */ u_int8_t  d_namlen;              /* Длина строки в d_name */

/* 0x08 */ char      d_name[MAXNAMLEN + 1]; /* Имя с длиной <= MAXNAMLEN */

};

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

На развалинах империи

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

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

□ В суперблоке обновляется структура fs_cstotal (количество свободных inode и блоков данных в разделе).

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

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

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

□ В inode удаляемого файла обнуляются поля di_mode (IFMT, права доступа), di_nlink (количество ссылок на файл) и di_size (размер файла).

□ В inode удаляемого файла затираются нулями поля di_db (массив указателей на 12 первых блоков файла) и di_ib (указатель на блок косвенной адресации).

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

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