Посилання на файли і каталоги

У NTFS файлу може бути привласнене більше одного імені; це відбувається при створенні жорсткого посилання (hard link). Жорстке посилання не відрізняється від початкового імені файлу, і для неї в індексі батьківського каталога створюється запис, який вказує на той же запис MFT, що і вихідне ім'я. Лічильник посилань в заголовку запису MFT збільшується на 1 при створенні жорсткого посилання, причому запис не звільняється до тих пір, поки її лічильник посилань не зменшиться до 0. Іншими словами, якщо вихідне ім'я файлу видаляється, але жорстке посилання продовжує існувати, файл видалений не буде. Запис MFT містить по одному атрибуту $FILE_NAME для кожного з імен своїх жорстких заслань. Жорсткі посилання створюються лише в межах того ж тому.

У NTFS 3.0+ з'явився новий механізм точок підключення (reparse points), які можуть використовуватися для створення посилань на файли, каталоги і томи. Точка підключення є спеціальним файлом або каталогом, який містить інформацію про той об'єкт, на який він посилається. Точки підключеняя можуть зв'язуватися з файлами і каталогами, що знаходяться на тому ж томі, іншому томі або на віддаленому сервері. Точки підключення також можуть використовуватися для монтування тому в каталог замість букви диска (наприклад, Е:\). Символічне посилання є точкою підключення, що зв'язує два файли; перехід (junction) — точку підключення, що зв'язує два каталоги; накінець, точка монтування пов'язує каталог з томом. Механізм Windows Remote Storage Server використовує точки підключення для опису місцерозташування файлу або каталога на сервері.

Точки підключення є спеціальними файлами, а в їх атрибутах $STANDARD_INFORMATION і $FILE_NAMEвстановлюються відповідні прапори. Крім того, вони містять атрибут $REPARSE_POINT з інформацією про місцерозташування цільового файлу або каталога.

У NTFS інформація про точки підключення зберігається в індексі з файлу метаданих файлової системи \$Extend\$Reparse. Індекс сортується по файлових посиланнях, але не містить відомостей про місцезнаходження цільових файлів.

Окрім файлу $Reparse, NTFS зберігає інформацію про точки монтування в атрибуті $DATA кореневого каталога (запис MFT 5). Атрибут $DATA з ім'ям $MountMgrRemoteDatabase містить список цільових томів, на які посилаються точки підключення. Цей атрибут $DATA створюється лише в тому випадку, якщо у файловій системі існує точка монтування.

Ідентифікатори об'єктів

У NTFS версій 3.0+ існує додатковий метод адресації файлів і каталогів (окрім стандартної адресації по іменах каталогів/файлів або адрес записів MFT). Застосування або ОС може привласнити файлу унікальний 128-розрядний ідентифікатор об'єкту, який надалі використовується для посилання на об'єкт навіть в разі його перейменування або переміщення на іншій том. Продукти Microsoft використовують ідентифікатори об'єктів при впровадженні файлів. Ідентифікатор може використовуватися для посилання на впроваджений файл навіть після його переміщення.

У файла або каталога, якому привласнюється ідентифікатор об'єкту, створюється атрибут $ОBJECT_ID. Він містить ідентифікатор об'єкту, а також може містити додаткову інформацію про вихідний домен і том, на якому він був створений. Якщо потрібно буде знайти файл по ідентифікатору об'єкту, потрібно звернутись до індексу \$Extend\$0bjId. Індекс містить записи для всіх привласнених ідентифікаторів об'єктів у файловій системі.

Цей метод адресації може вплинути на роботу експерта, оскільки може виникнути необхідність в пошуку файлу по ідентифікатору об'єкту.

Алгоритми виділення

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

Невеликі каталоги складаються з одного вузла, що знаходиться в атрибуті $INDEX_RООT. Якщо записи не поміщаються в цьому атрибуті, ОС переміщає їх в індексний запис в атрибуті $INDEX_ALLOCATION. На цій стадії В-дерево містить лише один вузол, а $INDEX_RООT не містить елементів, окрім порожнього елементу, що посилається на дочірній вузол. Після заповнення індексного запису виділяється другий запис, і атрибут $INDEX_RООT використовується як кореневий вузол, дочірніми вузлами якого є два індексні записи. Після заповнення цих індексних записів виділяється третій, внаслідок чого кореневий вузол міститиме три дочірні вузли.

У протестованих мною системах тимчасові штампи і розміри в атрибуті $FILE_NAME оновлювалися з тією ж частотою, що і значення в атрибуті $STANDARD_ІNFORMATION у записі MFT файлу.

 

Методи аналізу

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

Як було показано в цьому розділі, аналіз імен файлів і індексів в NTFS є досить складним процесом. Він починається з пошуку кореневого каталога, представленого записом MFT 5. В процесі обробки каталогу ми переглядаємо вміст атрибутів $INDEX_RООT і $INDEX_ALLOCATION і обробляємо індексні елементи. У цих атрибутах зберігаються списки, які нахзиваються індексними записами і відповідають вузлам дерева. Кожен індексний запис містить один або декілька індексних елементів. Індексні записи також можуть містити вільні індексні елементи; у заголовку запису вказується, де знаходиться останній виділений елемент. Стан виділення індексних записів визначається по атрибуту $ВІТМАР каталогу. Існуючі файли можуть асоціюватися не лише з виділеними, але і з вільними індексними елементами, тому що каталоги зберігаються у вигляді В-дерев, які вимагають повторного сортування при додаванні і видаленні файлів.

Ім'я файлу також може відповідати точці підключення — посиланню або точці монтування. Цільовий об'єкт точки підключення визначається в атрибуті $REPARSE_POINT запису MFT. Компанія Microsoft визначила деяких типів точок підключення, але можливі і інші типи, специфічні для конкретних застосувань.

Фактори аналізу

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

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

При пошуку видалених файлів в каталозі програма повинна перевірити два можливі місця. Перше — вільні області кожного вузла в дереві індексу каталога, а друге — вільні записи MFT. Якщо ім'я файлу було стерте з індексу, але запис MFT ще існує, ми можемо визначити, що файл знаходився в каталозі, звернувшись до адреси MFT батьківського каталога в атрибуті $FILE_NAME. Переконаємося в тому, що наша програма аналізу проводить обидві перевірки при пошуку видалених файлів в каталогах.

Сценарій аналізу

В процесі дослідження ми вирішили протестувати програму Digital Investigator 4000 (DI4K), а для підтвердження результатів скористатися програмою FSAnalyzer 1000 (FSA1K), яка застосовувалася до теперішнього часу. На аналізованому комп’ютері з файловою системою NTFS знайдений каталог. Порівняння вмісту каталога в двох програмах виявляє ряд відмінностей:

1. Видалений файл aaa.txt не показується у вихідних даних DI4K, але присутній у виведенні FSA1K.

2. Дві програми виводять різні тимчасові штампи файлу mmm.txt. У DI4K вони відносяться до ранішого моменту, ніж в FSA1K.

3. Видалений файл www.txt показується у вихідних даних DI4K, але відсутній у виведенні FSA1K.

Для існуючих файлів результати збігаються. Аби розібратися в причинах що відбувається, ми запускаємо шістнадцятковий редактор і починаємо розбирати індекс каталога. Після ручної обробки атрибутів $INDEX_RООT і $INDEX_ALLОCATIОN з'ясовується, що індекс має структуру, показану на рис. 18.10(A).

З вмісту каталога видно, чому виникла перша проблема. Програма FSA1K вивела файл aaa.txt як видалений, не дивлячись на те, що він продовжує існувати. Ймовірно, вільний запис з'явився після видалення іншого файлу і переміщення елементу aaa.txt по вузлу. Новіша програма DI4K знайшла існуючий запис aaa.txt і не стала виводити вільний запис.

Друга проблема відноситься до тимчасових штампів файлу mmm.txt. Ми бачимо, що індексний елемент знаходиться в кореневому вузлі індексу, а його метадані зберігаються в записі MFT 31, показаному на рис. 2.10 (В). Ми обробляємо атрибут $STANDARD_INFORMATION записи MFT 31 і знаходимо тимчасові штампи, виведені програмою FSA1K. Перегляд тимчасових штампів в атрибуті $FILE_NAME індексного елементу виявляє тимчасові штампи, виведені в DI4K. Щоб взнати, яка інформація була точнішою, ми порівнюємо порядкові номера індексного елементу і запису MFT. З'ясовується, що в індексного елементу порядковий номер дорівнює 3, а в запису MFT — 4. Отже, запис MFT був виділений заново після видалення файлу mmm.txt, програма DI4K це відмітила і вивела дані з атрибуту $FILE_NAME індексного елементу.

Третя проблема відносилася до нового файлу www.txt; проте в індексі такого файлу немає. Пригадаємо, що говорилося раніше про «зависання» видалених файлів NTFS, що відбувається із-за перезапису видалених імен в індексах. Ми шукаємо запис MFT для імені www.txt; для цього в логічній файловій системі проводиться пошук рядка «www.txt» і Unicode. В результаті пошуку виявляється запис MFT 30, в якому вказаний запис батьківського каталогу 36, — запис того самого каталога, який ми аналізуємо. Можна зробити висновок, що нова програма DI4K не лише виводить інформацію про вільні елементи в індексі, але і шукає завислі файли.

У звіті ми документуємо всі знайдені відмінності. Жодна програма не видає помилкових даних, але виведення D14K було набагато точнішим.

Категорія прикладних даних

До унікальних особливостей файлової системи NTFS відноситься підтримка багатьох можливостей прикладного рівня. Йдеться про можливості, що підвищують ефективність роботи операційної системи або застосувань, але які проте не обов'язково включати у файлову систему. Жодна з можливостей прикладного рівня не є необхідною відносно головного призначення файлової системи — збереження і завантаження файлів. Більш того, користувач або застосування може заблокувати деякі з можливостей прикладного рівня. В цьому розділі розглядаються дискові квоти, журнали файлової системи і протоколювання змін. Я називатиму дані «необхідними», якщо вони критичні для роботи функції прикладного рівня, а не для реалізації основної функції файлової системи (збереження-вибірки даних).

Журнали файлових систем

Для підвищення надійності файлової системи компанія Microsoft включила в NTFS підтримку журналів. Журнал файлової системи дозволяє операційній системі швидше відновити коректний стан файлової системи. Пошкодження файлових систем зазвичай відбуваються при системних збоях під час запису даних у файлову систему. У журналі зберігається інформація про всі майбутні оновлення метаданих, а також створюються записи про їх успішне оновлення. Якщо перед тим, як в журналі буде зафіксований факт успішного оновлення, в системі станеться збій, ОС зможе швидко повернути систему в попередній стан.

Файл журналу NTFS представлений записом MFT 2; йому привласнено ім'я $LogFile. Цей запис MFT не має спеціальних атрибутів, а вміст журналу зберігається в атрибуті $DATA. Я виявив, що розмір файлу журналу складає близько 1-2 % загального розміру файлової системи. Про вміст журналу відомо дуже мало, хоча компанія Microsoft опублікувала деяку високорівневу інформацію в своій інструкції і в книзі «Inside Windows 2000».

Файл журналу ділиться на дві основні частини: область рестарту і протокольну область. Як показано на рис. 18.11, область рестарту містить дві копії структури даних, яка допомагає ОС вибрати транзакції для аналізу при виконанні відкату. У ній міститься покажчик на останню свідомо успешну транзакцію в протокольній області.

Протокольна область містить серію записів. Кожному запису відповідає логічний порядковий номер (LSN), який є унікальним 64-розрядним значенням. Номери LSN призначаються в порядку зростання. Протокольна область має кінцевий розмір, і коли в кінці файлу не залишається місця для створення нового запису, вона поміщається в початок файлу. У цій ситуації запис в кінці файлу журналу володітиме великим номером LSN, ніж в запису на початку файлу. Іншими словами, номери LSN назначаются записам на підставі часу їх створення, а не розташування у файлі. Записи, що стали непотрібними, замінюються при повторному заповненні журналу.

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

 створення файлу або каталога;

 зміна вмісту файлу або каталога;

 перейменування файлу або каталога;

 зміна будь-яких даних, що зберігаються в записі MFT файлу або каталога (ідентифікатор користувача, параметри безпеки і т. д.).

Окрім номера LSN кожен запис оновлення містить два важливі поля. У першому полі зберігається інформація про те, що збирається зробити виконувана операція; воно називається полем повернення. Друге поле містить протилежн інформацію про те, як відмінити операцію. Ці записи створюються перед виконанням транзакції файлової системи. Після виконання транзакції створюється ще один запис оновлення, що показує, що транзакція була успішно завершена. Вона називається записом закріплення.

Другий різновид записів — записи контрольних точок. Запис контрольної точки вказує, з якої позиції журналу повинна починати ОС при перевірці файлової системи. Windows створює один запис цього вигляду кожні п'ять секунд, і її номер LSN зберігається в області рестарту журналу.

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

На рис. 18.12 показаний покажчик з області рестарту до місцезнаходження останнього запису контрольної точки. Подальший перебір виявляє дві транзакції. В транзакції 1 є запис закріплення, тому система по вмісту поля повернення перевіряє правильність стану диска. Транзакція 2 не має запису закріплення, тому система по вмісту поля відміни переконується в тому, що жодне з передбачуваних змін не існує.

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

У заголовку кожного запису MFT зберігається останній номер LSN для файлу. Зокрема, його значення наводилося у вихідних даних istat в наведених раніше прикладах. По цьому значенню можна визначити відносний порядок зміни двох файлів.

Одна з транзакцій не була закріплена.

Фактори аналізу

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

Журнал змін

Журналом змін називається файл, в якому реєструються зміни у файлах і каталогах. Він існує в NTFS версій 3.0+ і може використовуватися застосуваннями для визначення файлів, що змінилися за деякий проміжок часу. У загальному випадку для виявлення змін застосування повинно перебрати всі файли і каталоги у файловій системі і порівняти їх часові штампи з пороговим значенням. У великих файлових системах ця процедура займе надто багато часу, але журнали змін значно спрощують її. У журналах змін перераховуються всі файли, до яких були внесені зміни.

У Windows будь-яке застосування може включати і відключати механізм журналу на свій розсуд. За умовчанням він відключений. З журналом асоціюється 64-розрядне число, яке змінюється при кожному включенні або відключенні. За допомогою цього числа застосування може визначити, що із-за відключення журналу деякі зміни виявилися втраченими. При відключенні журналу Windows видаляє файл в Windows 2000 і ХР.

Журнал змін зберігається у файлі \$Extend\$UsrJrnl. Зазвичай цьому файлу не виділяється один із зарезервованих записів MFT, і він володіє двома атрибутами $DATA. Перший атрибут з ім'ям $Мах містить базову інформацію про журнал. Другий атрибут з ім'ям $J містить сам журнал у вигляді списку записів змінного розміру. Кожен запис містить ім'я файлу, час зміни і тип зміни. Довжина запису залежить від довжини імені файлу. Кожен запис володіє 64-розрядним порядковим номером оновлення, або USN (Update Sequence Number). Номери USN використовуються для індексування записів в журналі і зберігаються в атрибуті $STANDARD_INFORMATION модифікованого файлу. USN відповідає зсуву усередині журналу в байтах, що дозволяє легко знайти запис по USN (тому що всі записи мають різні розміри). Запис не містить інформації про те, які дані змінилися; вказується лише тип змін.

У Windows максимальний розмір журналу обмежений. Якщо журнал досягає цього розміру, Windows перетворить файл в розріджений і продовжує додавати дані в кінець файлу. При виділенні нового кластера в кінці файлу перший кластер видаляється і стає розрідженим. Таким чином, все виглядає так, немов файл збільшується в розмірах, але насправді він містить одну і ту ж кількість виділених кластерів. Проте номери USN при такій схемі завжди збільшуються, тому що вони відповідають зсуву в байтах від початку файлу.

Фактори аналізу

Важко заздалегідь сказати, скільки інформації можна витягувати з цього файлу; немає гарантії, що механізм журналу буде включений. Більш того, при його відключенні Windows видаляє вміст файлу, причому відключення може проводитися будь-яким застосуванням. Якщо все ж допустити, що журнал був включений і його вмісту можна довіряти, вміст журналу може згодитися для реконструкції недавніх подій. Для файлу зберігається лише час останньої модифікації або створення, а журнал може містити інформацію про багато змін, хоча точні описи цих змін не будуть відомі.

Загальна картина

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

Створення файлу

В даному прикладі створюється файл \dirl\filel.dat; передбачається, що каталог dirl вже існує в кореневому каталозі.Розмір файлу складає 4000 байт, а розмір кластера дорівнює 2048 байт.

1. Створення файлу починається з читання першого сектора файлової системи і обробки завантажувального сектора для визначення розміру кластера, початкової адреси MFT і розміру запису MFT.

2. Ми читаємо з MFT перший запис (файл $МFT) і обробляємо його для визначення структури останніх записівMFT. Інформація зберігається в атрибуті $DATA.

3. Для нового файлу виділяється запис MFT. Аби знайти невживаний запис, ми обробляємо атрибут $ВІТМАР файлу $MFT. Перший вільний запис (304) виділяється новому файлу, а відповідний біт карти встановлюється в 1.

4. Відбувається ініціалізація запису MFT 304, для чого ми знаходимо запис в MFT і стираємо її вміст. У записі створюються атрибути $STANDARD_INFORMATION і $FILE_NAME, а тимчасові штампи ініціалізувалися поточним часом. В заголовку запису MFT встановлюється прапор використання.

5. Далі для файлу необхідно виділити два кластери; при цьому використовується атрибут $DATA файлу $Bitmap, що знаходиться в записі MFT 6. Два суміжних кластери, 692 і 693, знаходяться з використанням алгоритму оптимального підбору. Відповідні біти карти для кластерів встановлюються рівними 1. У кластери записується вміст файлу, і атрибут $DATA оновлюється адресами кластерів. У записі MFT оновлюються тимчасові штампи.

 

6. На наступному кроці створюється інформація про ім'я файлу. Інформація dirl шукається в кореневому каталозі, що знаходиться в записі MFT 5. Ми читаємо атрибути $INDEX_RООT і $INDEX_ALLОCATIОN і переміщаємося по відсортованому дереву. Після виявлення індексного елементу dirl з нього береться адреса запису MFT 200. Оновлюється час останнього звернення до каталога.

7. Обробка атрибуту $INDEX_RООT запису MFT 200 дає місцезнаходження файлу filel.dat. Для файлу створюється новий індексний елемент, і все дерево сортується заново. Це може привести до переміщення індексних елементів всередині вузла. В нового індексного елементу в полі базової адреси вказаний запис MFT 304, а тимчасові штампи і прапори задані відповідним чином. Для каталога оновлюється час останньої модифікації і звернення.

8. Кожен з перерахованих етапів може супроводитися створенням записів в журналі файлової системи $LogFile і журналі змін \$Extend\$UsrJrnl. Якщо в системі підтримуються квоти, новий розмір файлу включається в квоту користувача у файлі \$Extend\$Quota.

Зв'язки між компонентами і підсумковий стан системи показані на рис. 18.13.

Видалення файлу

Тепер поглянемо, що відбувається при видаленні файлу \dirl\filel.dat

1. Видалення файлу починається з читання першого сектора файлової системи і обробки завантажувального сектора для визначення розміру кластера, початкової адреси MFT і розміру запису MFT.

2. Ми читаємо з MFT перший запис (файл $МFT) і обробляємо його для визначення структури останніх записівMFT. Інформація зберігається в атрибуті $DATA.

3. Далі необхідно знайти каталог dirl, тому ми обробляємо запис MFT кореневого каталога (5) і переміщаємося по індексу в атрибутах $INDEX_RООT і $INDEX_ALLOCATION. З виявленого елементу dirl береться адреса запису MFT 200. Оновлюється час останнього звернення до каталога.

4. Ми обробляємо атрибут $INDEX_RООT запису MFT 200 і шукаємо в ньому елемент filel.dat. З'ясовується, що адреса MFT файлу відповідає запису 304.

5. Запис виключається з індексу, елементи вузла переміщаються і замінюють початковий елемент. Для каталогу оновлюється час останньої модифікації і звернення.

6. Запис MFT 304 звільняється скиданням прапора використання. Також обробляється атрибут $DATA файлу $Bitmap, і в ньому обнуляється біт даного запису.

7. Обробляються нерезидентні атрибути запису MFT 304; відповідні кластери переводяться у вільне полягання в бітовій карті файлу \$Bitmap. В нашому випадку звільняються кластери 692 і 693.

8. Кожен з перерахованих етапів може супроводитися створенням записів в журналі файлової системи $LogFUe і журналі змін \$Extend\$UsrJrnl. Якщо в системі підтримуються квоти, новий розмір файлу віднімається з квоти користувача у файлі \$Extend\$Quota.

Підсумковий стан показаний на рис. 18.14. Звернемо увагу: при видаленні файлу в NTFS Windows не стирає покажчики. Таким чином, зв'язок між записом MFT і кластером зберігається, а зв'язок між ім'ям файлу і записом MFT теж продовжував би існувати, якби запис не був втрачений в результаті пересортовування.

Інше

В цьому розділі обговоримо питання — відновлення видалених файлів і перевірки цілісності.

Відновлення файлів

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

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

Інша обставина, яку необхідно враховувати при відновленні видалених файлів в NTFS, — пошук додаткових атрибутів $DATA. Образ містить видалені файли з декількома атрибутами $DATA, на яких не посилається жоден індексний елемент.

Аби відновити всі видалені файли в NTFS, необхідно провести в MFT пошук вільних записів. Після виявлення вільного запису ім'я визначається по

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

При відновленні файлів або перегляді видаленого вмісту можуть згодитися дані журналу файлової системи або журналу змін. Журнал змін не завжди активний, але в ньому можна знайти інформацію про час видалення і останнього редагування файлу.