Записи каталогів для довгих імен

Стандартні записи каталогу дозволяють представити файл, ім'я якого складається з 8 символів, а розширення — з 3. Якщо ім'я має велику довжину або містить спеціальні символи, для нього потрібні особливі записи каталогів — записи LFN (Long File Name). Окрім всіх записів LFN для файлу також створюється звичайний запис, причому записи LFN повинні передувати звичайному запису. Поля LFN-версії запису каталога перераховані в таблиці 16.7.

 

Таблиця 16.7 – Структура даних запису каталога LFN в FAT

Діапазон	Опис	Необхідність
0-0	Порядковий номер і ознака виділення (0хе5, якщо запис вільний)	Так
1-10	Ім'я файлу, символи 1-5 (Unicode)	Так
11-11	Атрибути файлу (0x0f)	Так
12-12	Зарезервовано	Немає
13-13	Контрольна сума	Так
14-25	Ім'я файлу, символи 6-11 (Unicode)	Так
26-27	Зарезервовано	Немає
28-31	Ім'я файлу, символи 12-13 (Unicode)	Так

 

Поле порядкового номера містить лічильник записів, необхідних для зберігання імені файлу. Першому запису відповідає порядковий номер 1. Порядковий номер збільшується на 1 для кожного запису LFN аж до останнього, в якому він об'єднується із значенням 0x40 порозрядною операцією OR. При виконанні цієї операції результат містить 1 у всіх розрядах, в яких хоч би один з двох операндів містить 1.

Записи LFN розташовуються в зворотному порядку перед записом короткого імені файлу. Отже, перший запис, який ми знаходимо в каталозі, є останнім записом LFN для файлу і має найбільший порядковий номер. Невикористовувані символи доповнюються кодами 0xff, а ім'я завершується символом NULL за наявності вільного місця.

Поле атрибутів запису LFN має бути рівне 0x0f. Контрольна сума обчислюється з використанням короткого імені файлу і має бути однаковою для всіх записів LFN. Якщо контрольна сума запису LFN не збігається з контрольною сумою відповідного короткого імені, можливо, використання ОС без підтримки довгих імен привело до пошкодження каталогу. Алгоритм обчислення контрольної суми перебирає символи імені, на кожному кроці зсуває поточну контрольну суму на один біт вправо і додає ASCII-код наступної букви. В програмному коді С це виглядає так:

с = 0;

for (і = 0; і < 11; і++) {

// Зсув вправо

с = ((с & 0x01)? 0x80: 0) + (с» 1);

// Збільшення ASCII-коду символа

с = с + shortname;

}

А ось як виглядають два записи LFN і один звичайний запис для файлу в кореневому каталозі тестового образу (лістинг 16.7):

Лістинг 16.7 – Два записи LFN і один звичайний запис для файлу в кореневому каталозі

# dcat -f fat fat-4.dd 1632 | xxd

[...]

0000064: 424e 0061 006d 0065 002e 000f 00df 7200 BN.a.m.e......r.

0000080: 7400 6600 0000 ffff ffff 0000 ffff ffff t.f.............

0000096: 014d 0079 0020 004c 006f 000f 00df 6e00.M.y..L.o....n.

0000112: 6700 2000 4600 6900 6c00 0000 6500 2000 g..F.i.l.e....

0000128: 4d59 4cdf 4e47 7e31 5254 4620 00а3 347е MY10nG~lRTF..4-

0000144: 4a30 8830 0000 4a33 7830 1a00 8fl3 0000 J0.0..J3x0......

Перший запис знаходиться по-перше в двох рядках. Байт 75 містить код 0x0f, по якому ми взнаємо, що це запис LFN. Порядковий номер зберігається в байті 64, він дорівнює 0x42. Виключивши результат операції OR з кодом 0x40 (маркер останнього запису LFN), ми отримаємо 0x02; отже, файл представляється двома записами LFN. Контрольна сума в байті 77 рівна 0xdf. Пізніше ми зможемо використовувати це значення при перевірці запису короткого імені. Перші п'ять символів запису (хоча це і не перші символи імені) знаходяться в байтах 65-74 і утворюють рядок «Name». Друга група символів в байтах 78-89 утворює рядок «rtf». Останні символи заповнені кодом 0xffff. Остання група символів в байтах 92-95 теж містить 0xffff. Отже, довге ім'я завершується рядком «Name.rtf».

В другого запису, що починається з байта 96, теж встановлений атрибут LFN, а його порядковий номер дорівнює 1. Контрольна сума збігається з контрольною сумою першого запису, 0xdf. Запис містить групи символів «My Lo», «Ng Fil» і «е». Порядковий номер запису дорівнює 1, а значить, це останній запис LFN для даного імені. Об'єднуючи символи двох записів, ми отримуємо «My Long File Name.rtf». Коротка версія цього імені знаходиться в третьому записі — звичайному записі каталога з ім'ям «MYLONG~l.RTF».

Тепер можна перевірити контрольну суму, але для цього необхідно знати ASCII-коди символів в двійковому вигляді. Їх значення перераховані в таблиці 16.8.

Таблиця 16.8 – ASCII-коди символів для записів LFN з наведеного прикладу

Символ	Шістн.	Двійк.
М	0x4d	0100 1101
Y	0x59	0101 1001
L	0x4с	0100 1100
О	0x4f	0100 1111
N	0х4е	0100 1110
G	0x47	0100 0111
~	0х7Е	0111 1110
I	0x31	0011 0001
R	0x52	0101 0010
Т	0x54	0101 0100
F	0x46	0100 0110

Всі обчислення проводитимуться в двійковому форматі, аби уникнути постійних перетворень. На першому кроці нашої змінної check присвоюється значення першої букви імені, «М»:

check = 0100 1101

На кожному з 10 подальших кроків ми здійснюємо циклічний зсув поточної контрольної суми вправо і додаємо чергову букву. Зсув поточного значення і збільшення «Y»:

check = 1010 0110

check = 1010 0110 + 0101 1001 = 1111 1111

Зсув (який нічого не змінює, тому що значення складається лише з 1) і збільшення «L»:

check = 1111 1111

check = 1111 1111 + 0100 1100 = 0100 1011

Зсув і збільшення «О»:

check = 1010 0101

check = 1010 0101 + 0100 1111 = 1111 0100

Надалі рядок зсуву опускається, а показується лише складання. Зсув і збільшення «N»:

check = 0111 1010 + 0100 1110 = 1100 1000

Зсув і збільшення «G»:

check = 0110 0100 + 0100 0111 = 1010 1011

Зсув і збільшення «~»:

check = 1101 0101 + 0111 1110 = 0101 0011

Зсув і збільшення «1»:

check = 1010 1001 + 0011 0001 = 1101 1010

Зсув і збільшення «R»:

check = 0110 1101 + 0101 0010 = 1011 1111

Зсув і збільшення «Т»:

check = 1101 1111 + 0101 0100 = 0011 0011

Зсув і збільшення «F»:

check = 1001 1001 + 0100 0110 = 1101 1111 = 0xdf

Навряд чи нам доведеться обчислювати контрольні суми вручну, але принаймні ми навели процес того, як це робиться. Зрештою ми отримуємо того ж значення 0xdf, яке ми бачили в кожному із записів LFN.

Для отримання інформації про записи каталогу можна скористатися програмою fls з пакету TSK. Програма fls виводить вміст LFN, при цьому короткі імена вставляють в круглі дужки:

# fls –f fat fat-2.dd

r/r 3: FAT DISK (Volume Label Entry)

r/r 4: RESUME-1.RTF

r/r 7: My Long File Name.rtf (MYLONG~1.RTF)

r/r * 8: _ile6.txt

В перших двох рядках відображується мітка тому і записи каталогів з короткими іменами, що наведені вище. В третьому рядку показано довге ім'я, яке ми недавно аналізували, а за ним слідує ім'я видаленого файлу _jle6.txt. Зірочка перед ім'ям файлу вказує на те, що він видалений, а перша буква імені відсутня тому, що таким чином позначаються вільні записи. Число перед ім'ям вказує адресу запису каталога з додатковою інформацією.

Лекція 17 NTFS: основні концепції

Одна з найважливіших концепцій для розуміння архітектури NTFS свідчить, що всі службові дані зберігаються у файлах. Зокрема, це відноситься до адміністративних даних базової файлової системи, що зазвичай приховуються в інших файлових системах. Файли з адміністративними даними можуть знаходитися в будь-якому місці тому, як звичайні файли. Таким чином, на відміну від інших файлових систем NTFS не володіє жорстко заданою структурою. Вся файлова система рахується областю даних, і будь-який сектор може бути виділений файлу. Єдина фіксована вимога свідчить, що перші сектори тому містять завантажувальний сектор і завантажувальний код.

Концепції MFT

«Серцем» NTFS є головна файлова таблиця MFT (Master File Table), що містить інформацію про всі файли і каталоги. Кожен файл і каталог представлений як мінімум одним записом таблиці, причому записи самі по собі дуже прості. Їх розмір складає 1 Кбайт, але лише перші 42 байти мають певне призначення. В останніх байтах зберігаються атрибути — невеликі структури даних, що виконують строго спеціалізовану функцію. Наприклад, один атрибут використовується для зберігання імені файлу, а інший — для зберігання його вмісту. На рис. 17.1 показана основна структура запису MFT із заголовком і трьома атрибутами.

Запис, показаний на рисунку 17.1 містить три атрибути.

Microsoft називає кожен елемент таблиці файловим записом (file record), але я вважаю, що їх простіше і зручніше називати записами MFT. Кожному запису на підставі її місцезнаходження в таблиці привласнюється адреса, починаючи з 0. В даний час розмір всіх записів дорівнює 1024 байт, проте його точне значення визначається в завантажувальному секторі.

MFT, як і всі структури NTFS, є таблицею. Ситуація дещо ускладнюється тим, що MFT містить запис для представлення себе самої. Перший запис таблиці називається $MFT і задає місцезнаходження MFT на диску. Фактично це єдине місце, в якому вказується місцерозташування MFT; отже, цей запис необхідно обробити для визначення структури і розміру MFT. Початкова адреса MFT задається в завантажувальному секторі, який завжди розташовується в першому секторі файлової системи. Як показано на рис. 17.2, завантажувальний сектор використовується для пошуку першого запису MFT, який показує, що таблиця MFT фрагментована і займає кластери 32-34 і 56-58. У NTFS, як і в FAT, дисковий простір виділяється у вигляді кластерів, тобто груп суміжних секторів.

У реалізації MTFS компанії Microsoft таблиця MFT починається з мінімального розміру і розширюється в міру необхідності. Теоретично ОС може створити фіксоване число записів при створенні файлової системи, але динамічна природа реалізації Microsoft дозволяє легко розширити файлову систему при додаванні додаткового дискового простору за рахунок об’єднання дисків. Microsoft не видаляє запису MFT після їх створення.

Вміст запису MFT

Розмір кожного запису MFT визначається в завантажувальному секторі, але у всіх версіях Microsoft використовуються 1024-байтові записи. Перші 42 байти містять 12 полів, а останні 982 байти не мають фіксованої структури і заповнюються атрибутами. Запис MFT можна порівняти з великою скринею для зберігання речей. Зовні на скрині написані основні відомості про власника — ім'я і адреса (аналог фіксованих полів записів MFT). Скриня зазвичай залишається пустою, але в неї можна покласти будь-який предмет, розмір якого менший розміру скрині. Записи MFT теж не мають фіксованої структури і містять атрибути, в яких зберігається конкретна інформація.

В першому полі кожного запису MFT зберігається сигнатура; в стандартних записів це ASCII-рядок «FILE». Якщо в записі виявлена помилка, в якості сигнатури може використовуватися рядок «BAAD». Поле прапорів вказує, чи використовується запис і чи представляє вона каталог. Стан виділення запису MFT також можна визначити по атрибуту $ВІТМАР у файлі $MFT.

Якщо атрибути не поміщаються в одному записі, для файлу створюються декілька записів MFT. В цьому випадку перший запис називається базовим записом MFT, а його адреса зберігається в одному з фіксованих полів всіх останніх записів.

Адреси записів MFT

У MFT використовується послідовна 48-розрядна адресація записів, при цьому першому запису привласнюється адреса 0. Максимальна адреса MFT змінюється у міру розширення MFT і визначається діленням розміру $MFT на розмір одного запису. Microsoft називає цю послідовну адресу файловим номером (file number).

Кожен запис MFT також містить 16-розрядний порядковий номер, який автоматично збільшується при створенні запису. Для прикладу розглянемо запис MFT 313 з порядковим номером 1. Файл, якому був виділений запис 313, видаляється, а запис повторно виділяється новому файлу. При повторному виділені запису привласнюється новий порядковий номер 2. Адреса MFT об'єднується з порядковим номером (займає старші 16 біт) і формує 64-розрядну базову адресу файлу (див. рис. 17.3).

NTFS використовує базову адресу для звернення до записів MFT, тому що порядковий номер спрощує виявлення пошкоджень файлової системи. Наприклад, якщо в процесі виділення структур даних для файлу в системі станеться збій, по порядковому номеру можна буде визначити, чи містить структура даних адресу запису MFT, що залишилася від попереднього файлу або ж є частиною нового файлу. Крім того, порядковий номер можна використовувати при відновленні видаленого вмісту. Наприклад, якщо є вільна структура даних з базовою адресою файлу, ми можемо визначити, чи проводилося повторне виділення запису MFT з часу її використання в цій структурі даних. Порядковий номер може згодитися під час дослідждення, але для простоти я в основному використовуватиму файлові номери, тобто адреси записів MFT.