здравствуйте, вот начал разбираться со структурой ntfs, открыл флэшку в DiskExplorer for Ntfs, открыл коневой каталог->тело $INDEX_ROOT
а дальше не понятно как интерпритировать эти данные?
я понял так — тут есть единственная Index Entry с флагом = 1, в документации написано что если флаг = 1 значит эта запись указывает на sub-node, и в ней появляется поле VCN со смещением L-8 (в моем случае получается 0x20), у меня по этому смещению нули, для чего нужны оставшиеся 16 байт не понятно.
так же не ясно к чему относится это VCN, т к структура Index Entry описана для атрибуда $INDEX_ALLOCATION и куда спихнуть это поле из $INDEX_ROOT?
L>я понял так — тут есть единственная Index Entry с флагом = 1, в документации написано что если флаг = 1 значит эта запись указывает на sub-node, и в ней появляется поле VCN со смещением L-8 (в моем случае получается 0x20), у меня по этому смещению нули, для чего нужны оставшиеся 16 байт не понятно.
Поле 0x10 по смещению 0x10 означает, что entries начинаются со смещения 0x10 относительно поля со смещением 0x10.
Т.е. Index Entry начинается в приведенном дампе со смещения 0x20.
Флаг у неё 3, что означает, что она последняя, но перед ней есть ссылка на sub-node.
Номер этого subnode — 4
L>так же не ясно к чему относится это VCN, т к структура Index Entry описана для атрибуда $INDEX_ALLOCATION и куда спихнуть это поле из $INDEX_ROOT?
По поводу номера sub-node: Размер блока 4к, его номер 4 т.е. надо прочитать 4к из $INDEX_ALLOCATION по смещению 16к
В его заголове также будет номер 4
L>>я понял так — тут есть единственная Index Entry с флагом = 1, в документации написано что если флаг = 1 значит эта запись указывает на sub-node, и в ней появляется поле VCN со смещением L-8 (в моем случае получается 0x20), у меня по этому смещению нули, для чего нужны оставшиеся 16 байт не понятно.
MS>Поле 0x10 по смещению 0x10 означает, что entries начинаются со смещения 0x10 относительно поля со смещением 0x10.
MS>Т.е. Index Entry начинается в приведенном дампе со смещения 0x20.
да со смещениями я напутал.
MS>Флаг у неё 3, что означает, что она последняя, но перед ней есть ссылка на sub-node. MS>Номер этого subnode — 4
не знал что флаги могут комбинироваться.
L>>так же не ясно к чему относится это VCN, т к структура Index Entry описана для атрибуда $INDEX_ALLOCATION и куда спихнуть это поле из $INDEX_ROOT?
MS>По поводу номера sub-node: Размер блока 4к, его номер 4 т.е. надо прочитать 4к из $INDEX_ALLOCATION по смещению 16к MS>В его заголове также будет номер 4
т е система может ни чего не оставлять в $INDEX_ROOT даже если там есть место?
L>т е система может ни чего не оставлять в $INDEX_ROOT даже если там есть место?
Может поступить как угодно, вплоть до того, что выделить дополнительную MFT запись, в неё поместить весь root (имен 10-12 туда влезет), а в главной записи завести attribute list.
Это по сравнению с тем, чтобы (если место в основной записи для root заполнилось) — выделить кластер для index allocation, завести аттрибуты index_allocation и index_bitmap и перенести полностью или частично файлы из root в index.
Но есть ньюансы:
Обычно три файла в каталоге $Extend свободно помещаются в root, но если их поместить в index_allocation, то WinXP не распознает такой NTFS, хотя естественно с точки зрения chkdsk ( и более старших windows ) этот том нормальный.
Есть еще подобные known issue связанные с драйвером NTFS.
Одна из них — количество фрагментов например sparsed или compressed(не пробовал) файла.
Если их больше 10000 (наблюдал на 30 тыс), то 2K/XP увидев такой файл падают в синий экран, более старшие версии просто не открывают такой файл.
С точки зрения chkdsk — все нормально.
Здравствуйте, MShura, Вы писали:
L>>т е система может ни чего не оставлять в $INDEX_ROOT даже если там есть место? MS>Может поступить как угодно, вплоть до того, что выделить дополнительную MFT запись, в неё поместить весь root (имен 10-12 туда влезет), а в главной записи завести attribute list. MS>Это по сравнению с тем, чтобы (если место в основной записи для root заполнилось) — выделить кластер для index allocation, завести аттрибуты index_allocation и index_bitmap и перенести полностью или частично файлы из root в index.
MS>Но есть ньюансы: MS>Обычно три файла в каталоге $Extend свободно помещаются в root, но если их поместить в index_allocation, то WinXP не распознает такой NTFS, хотя естественно с точки зрения chkdsk ( и более старших windows ) этот том нормальный.
MS>Есть еще подобные known issue связанные с драйвером NTFS. MS>Одна из них — количество фрагментов например sparsed или compressed(не пробовал) файла. MS>Если их больше 10000 (наблюдал на 30 тыс), то 2K/XP увидев такой файл падают в синий экран, более старшие версии просто не открывают такой файл. MS>С точки зрения chkdsk — все нормально.
получается в моем случае корень дерева переносится куда-то в index_allocation что тоже не очень приятно...
спасибо, буду крутить дальше
как интерпритировать эти данные?
