OSDev

Самая обширная документация по NTFS здесь: http://sourceforge.net/projects/linux-n ... mentation/
В принципе, структура более-менее понятна, хотя и очень запутана. Я пока ещё пробую сам разобраться. Не ясны следующие моменты.
1. Как предполагается правильный первоначальный разбор файловой системы? Понятно, что корень зла - $MFT. Но в какой последовательности раскручивать систему? В частности, если MFT повреждён, но сохранилась резервная копия $MFTMirr. Ведь резервируются только первые четыре записи, а запись о корневой директории шестая по счёту.
2. Какую роль играет атрибут $BITMAP в записи директории NTFS?
3. Насколько может быть фрагментирован сам $MFT? Т.е. может ли так оказаться, что его data run слишком велик, поэтому его атрибут $DATA вдруг стал размещается где-то не стороне в нерезидентном атрибуте $ATTRIBUTE_LIST? Как такую бороду раскручивать?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

$MFT сам MFT
$MFTmirr копия первых 16 записей MFT, размещенная посередине диска
$LogFile файл поддержки журналирования (см. ниже)
$Volume служебная информация - метка тома, версия файловой системы, т.д.
$AttrDef список стандартных атрибутов файлов на томе
$. корневой каталог
$Bitmap карта свободного места тома
$Boot загрузочный сектор (если раздел загрузочный)
$Quota файл, в котором записаны права пользователей на использование дискового пространства (начал работать лишь в NT5)
$Upcase файл - таблица соответствия заглавных и прописных букв в имен файлов на текущем томе. Нужен в основном потому, что в NTFS имена файлов записываются в Unicode, что составляет 65 тысяч различных символов, искать большие и малые эквиваленты которых очень нетривиально.

Вот немного инфы http://www.ixbt.com/storage/ntfs.html

Станислав, структуру NTFS я в этих рамках знаю. На iXBT, кстати, мало инфы, для разработки драйвера ФС её недостаточно. Самая полная инфа в ссылке, что я привёл.

По третьему пункту подозреваю, что хотя теоретически всё сделано для устранения фрагментации $MFT, на практике при определённых условиях он действительно может оказаться фрагментированным и атрибут $DATA видимо может уползти в нерезидентный атрибут $ATTRIBUTE_LIST. Наверное, на первом этапе надо восстанавливать и сохранять полное размещение $MFT в такой последовательности. Сначала ищем атрибут $DATA и сохраняем его data run. Если атрибут не нашёлся, ищем атрибут $ATTRIBUTE_LIST и далее ищем атрибут $DATA в его нерезидентной части. Кстати, может ли быть вложенный атрибут $ATTRIBUTE_LIST? Видимо, в этом нет большого смысла. Если и в нерезидентной части списка атрибутов не удалось найти, считаем, что первая запись $MFT побита компьютерной молью и делаем то же самое с $MFTMirr. Кто что думает?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

На самом деле, копия первых 4, если их совокупный размер больше кластера, или столько, сколько влезет в один кластер. И не посередине диска. XP как раз размещает посередине сам MFT в целях минимизации времени доступа к нему.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Вот ещё немного http://www.ntfs.com/ntfs-partition-boot-sector.htm
Я так понял, что с чтением списка файлов из корневой папки(например) у вас уже проблем нету?

Саму корневую папку читаю, однако пока её ещё не парсил.
Вот ещё открытый вопрос: нафига в записях MFT имена файлов??

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Кто-нибудь может мне помочь написать удолялку файлов с NTFS. А то у меня ни виндоус ни линукс его не удаляют пишут ошибка ввода вывода.

Может, проблема в слишком длинном полном имени? Или, возможно, нечто похожее на использование неопределенных атрибутов в FAT - к примеру когда прописываешь для файла атрибут 40h путем прямого доступа к диску, то винды отказываются удалять такой файл (некоторые вирусы и антивирусы пользуются этой возможностью, я тоже раньше использовал два не определенных в спецификации бита для хранения дополнительных флагов).

Для разработки драйвера ФС инфы там воодще снету можно сказать.
Yoda как вы находите сектор где лежит MFT из заголовка и какого формата этот файл, поделитесь плз.
из этого заголовка
;bpb db ' ' ;0
;bytes_per_sector dw 512 ;8
;sectors_per_cluster db 8 ;10
;reserved_sectors dw 2 ;11
; db 0,0,0 ;13 always 0
; dw 0 ;16 not used by NTFS
; db 0F8h ;18 media byte
; dw 0 ;19 always 0
; dw 0 ;21 sectors per track
; dw 0 ;23 number of heads
;hidden_sectors dd 0 ;25
; dd 0 ;29 not used by NTFS
; dd 0 ;33 not used by NTFS
; dq 0 ;37 Total Sectors
; dq 2 ;45 Logical Cluster Number for the file $MFT
; dq 0 ;53 Logical Cluster Number for the file $MFTMirr
; dd 0 ;61 Clusters Per File Record Segment
; dd 0 ;65 Clusters Per Index Block
; dq 0 ;69 Volume Serial Number
; dd 0 ;77 Checksum




Я пошарил по NTFS записям в dmde-free-2.2.2-win32-gui, там есть команды поиска записи MFT или Папки. Мне для изучения Фат очень помог такой метод. У меня получалось почемуто что сектор MFT=LogicalCluster_$MFT * sectors_per_cluster+hidden_sectors

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


1. Вся файловая система состоит из кластеров. Даже загрузочный сектор. Это базовая единица для NTFS. Поэтому везде фигурируют кластеры. Количество секторов в кластере определяется полем "sectors_per_cluster" в загрузочном секторе. Таким образом, для получения сектора нужно умножать нужный кластер на кол-во секторов в кластере.
2. Кластер, в котором лежит начало (первая запись) MFT указан в поле "Logical Cluster Number for the file $MFT". Не забываем, что там 8 байт (64-битное число). Естественно, домножаем на кол-во секторов в кластере и, если диск разбит на разделы, добавляем смещение к началу раздела (hidden sectors).


Это - линейный перечень так называемых "записей". Размер записи хитрым образом определяется байтом в загрузочном секторе "Clusters Per File Record Segment". Если этот байт - положительное число, то это число задаёт количество кластеров в одной записи. Если отрицательное, то это - степень двойки, задающая размер записи в байтах. Например, если там -9, то запись имеет размер 2^9 = 512 байт.
Точно так же определяется размер индексного блока (составная часть директории) по полю "Clusters Per Index Block".

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>