Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Принцип сортировки NTFS_RECORD - ов в MFT.

Страницы: < 1 2 3 >
Riply © (2007-06-23 07:06:00)
Здравствуйте !
Уже почти целый день бьюсь и никак не могу понять:
по какому принципу отсортированы записи в MFT :(
В общем случае, задача звучит так: по имени файла определить "номер записи в MFT".
Если постараться, то, вроде, ее можно свести к
"написанию" функции сравнения двух записей в MFT:
function Ntfs_RecordCompare(const pRec1, pRec2: PFILE_RECORD_HEADER): integer;
При помощи "метода научного тыка", можно сделать (ну очень шаткое) предположение,
что результат этой функции зависит от следующих параметров FILE_RECORD_HEADER:
Ntfs.Usn: Int64;
// The Update Sequence Number of the NTFS record.
Flags: USHORT;
// A bit array of flags specifying properties of the MFT entry.
// The values defined include: 0x0001 = InUse, 0x0002 = Directory
BytesInUse: ULONG;
// The number of bytes used by the MFT entry.
Сюда же надо добавить параметры из FILENAME_ATTRIBUTE
DirectoryFileReferenceNumber: ULONGLONG;
// The file reference number of the directory in which the filename is entered.
NameType: UCHAR;
//The type of the name.A type of zero indicates an ordinary name, a type of one indicates
//a long name corresponding to a short name, and a type of two indicates a short
//name corresponding to a long name.
А также, от того является ли данная запись, записью "системного файла" или нет.
То что зависит от NameType, у меня вообще в голове не укладывается.
Остальные, хоть как-то да можно объяснить( с натяжкой) :)
P.S. Что-то я совсем запуталась :(

vpbar (2007-06-26 15:21:00) [21]
>>Игорь Шевченко © (26.06.07 11:21) [20]
Прочитал после моего сообщения (видно страница не успела обновиться). Спасибо не знал. Хотя по видимомо этот FileID тотже что и для GetFileInformationByHandle (в ней идет обращение к NTQueryInformationFile).

А потом по этому FileID можно найти файл (определить имя, размер и т.д). А то если нет, то я не буду пока искать более подробную инфу по NTQueryInformationFile

Riply (2007-06-26 14:36:00) [22]
>[17] Игорь Шевченко © (25.06.07 15:40)
>Оно и есть. В приложении описание структур NTFS и примеры работы через FILEID
С этим приложением, с грехом попалам, вроде, разобралась.
Правда, не совсем уверена, что приложения у нас одинаковые: нет у меня рассуждений о том, что
"when you try to open an file with a filenumber that doesn't exist,
it returns a handle to the file that has the largest possible filenumber
under the number you specified"

>[18] Игорь Шевченко © (26.06.07 09:49)
>Есть такая полезная функция Nt(Zw)QueryInformationFile.
>Указывая в качестве FileInformationClass FILE_INTERNAL_INFORMATION как раз получается заветный FileID для известного файла.
>А у файлов метаданных NTFS эти самые FileID's ваще фиксированные.
Попробовала: действительно, полезная. :) Спасибо.

Что же. Для начала, не все так плохо, как кажется :)
Теперь у нас есть широкие возможности, для работы с файловой системой.
Но, есть и ложка дегтя:
Для работы, нам необходим FILE_ANY_ACCESS уровень доступа (для получения FileID).
Я понимаю, что с этим уровнем, нам доступны практически все файлы в системе,
но хочеться вообще убрать ограничение.
Это реально. Нужно научиться находить "файловую запись" только по имени файла, без его открытия.
И здесь, к сожалению, если я не ошибаюсь, FILEID - нам не помошник :(
Перебирая файлы на диске (через MFT) и просматривая их св-ва,
я убедилась, что "исходно" FILEID не нулевой у очень ограниченного кол-ва файлов.
При открытии какого-то файла ID у него появляется и, даже, остается после его закрытия.
Но нам от этого пользы мало :(
Пытаюсь делать так. (Допустим, мы ищем C:\Dir1\Dir2\Dir3\Test.txt)
Открываем в MFT корневую директорию и в ее IndexRoot атрибутах пытаемся найти Dir1.
Найдя Dir1 начинаем просматривать ее(Dir1) IndexRoot, в поисках Dir2 и т.д.
Вот "просматривать" INDEX_ROOT у меня (пока) и не получается.
А может, надо искать вовсе не в INDEX_ROOT ?
P.S.
Когда восстанавливают информацию, идут другим путем:
Начинают с удаленного файла.
В нем есть ссылка на директорию, в которой он находился, в которой есть ссылка... и т.д.
С оговоркой: если я правильно поняла :)

Игорь Шевченко (2007-06-26 11:21:00) [23]
vpbar (25.06.07 14:44) [15]

> Может найдете что нибудь позволяющее получить целочисленный
> идентификатор(ID) для файла (типа i-node в unix системах)
> чтоб затем по этому ID можно было найти файл (определить
> имя, размер и т.д).

Пост № 18 читай

vpbar (2007-06-26 11:10:00) [24]
>>[16]Riply ©
>> Например, через IoControlDevice
Ууу. Муторно. К тому же IoControlDevice , по-моему, работать будет только под админом.
Видимо в данном случае нет нормальных решений.

Игорь Шевченко (2007-06-26 09:49:00) [25]
Riply © (25.06.07 15:05) [16]

Есть такая полезная функция Nt(Zw)QueryInformationFile. Указывая в качестве FileInformationClass FILE_INTERNAL_INFORMATION как раз получается заветный FileID для известного файла. А у файлов метаданных NTFS эти самые FileID's ваще фиксированные.

Игорь Шевченко (2007-06-25 15:40:00) [26]
Riply © (25.06.07 15:05) [16]

Оно и есть. В приложении описание структур NTFS и примеры работы через FILEID

Riply (2007-06-25 15:05:00) [27]
> [15] vpbar (25.06.07 14:44)
>Нашел только GetFileInformationByHandle которая вроде возвращает чтото похожее ID
>этим nFileIndex найти файл - непонятно.
Например, через IoControlDevice

> [14] Игорь Шевченко © (25.06.07 12:19)
Игорь, в "моем Неббете" (Windows NT 2000 Native API Reference) ничего подобного я найти не сумела :(
Может у меня он "неправильный" ? :)
Или надо искать другую его книгу ?

vpbar (2007-06-25 14:44:00) [28]
Звиняйте, что лезу. Но просьба - развивайте тему. Может найдете что нибудь позволяющее получить целочисленный идентификатор(ID) для файла (типа i-node в unix системах) чтоб затем по этому ID можно было найти файл (определить имя, размер и т.д). А то я искал искал, но не нашел.
Нашел только GetFileInformationByHandle которая вроде возвращает чтото похожее ID ( http://vsokovikov.narod.ru/New_MSDN_API/Menage_files/str_by_handle_file_information.htm) но как затем по этим nFileIndex найти файл - непонятно.
Так что, успехов.

Игорь Шевченко (2007-06-25 12:19:00) [29]
Собственно, FILEID - это индекс для файла в файле $MFT.

A file ID is the number of the file, like the inode number on unix systems, $Mft has filenumber 0 and is the first entry (in itself). The Openfilebyid allows you to go through all the files and folder on the volume, you could just write one for loop which will open and analyze/defragment all your files and folders. When you call the function with fileId 0 for instance it will return you handle to the $Mft,
when you try to open an file with a filenumber that doesn't exist, it returns a handle to the file that has the largest possible filenumber under the number you specified and gives you the filenumber of that file.
In other words you start by trying to open the largest possible filenumber 0xFFFFFFFF and you will get a handle to lets say file 45000, next you try 44999 and if it exists good and you do your stuff and defragment the file or folder, otherwise you get the next file that exists (e.g. 44587 ) and so on.

Riply (2007-06-25 11:40:00) [30]
> [12] Игорь Шевченко © (25.06.07 10:16)
> По FILEID
А где такой ID живет ? В тех структурах, которые я "передирала" из С++ ничего похожего нет.

>Я же говорил, читай Неббета. Марш в библиотеку!
Маршаю !
P.S.
Хорошо еще, что послали в библиотеку к Неббету, а не к брату во Христе :)

Игорь Шевченко (2007-06-25 10:16:00) [31]

> по какому принципу отсортированы записи в MFT :(

По FILEID

Я же говорил, читай Неббета. Марш в библиотеку!

Riply (2007-06-24 14:18:00) [32]
>[10] Riply © (24.06.07 14:10)
> для каждого файла, в MFT существует NTFS_RECORD
Порушенную или подвегшуюся атаке "самопрячущихся" троянов систему не рассматриваем. (пока :)

Riply (2007-06-24 14:10:00) [33]
>[9] tesseract © (24.06.07 12:28)
>NTFS использует B-tree организацию, какой номер записи?.

"The filename attribute is always resident." (с) Gary Nebbett
Отсюда делаем вывод, что для каждого файла, в MFT существует NTFS_RECORD,
сожержащая базовую информацию о файле "внутри себя" (в том числе и его имя).
Эту запись можно найти, например, используя FileReferenceNumber.
Следовательно, можно построить соответствие Файл ---> NTFS_RECORD.
Порядковый номер этой записи и имеется ввиду.
Использование же ATTRIBUTE_LIST для хранения атрибутов файла, ничего не меняет,
т.к. внутри MFT все равно есть NTFS_RECORD с filename attribute, содержащий еще и ссылку на этот лист.

>NTFS использует B-tree организацию
Да, использует. Например, в таких структурах как: NTFS_RECORD_HEADER с типом 'INDX' (INDEX_ROOT)
или в атрибутах типа AttributeIndexRoot, один из вариантов - хранение (резидентно или нет) списка файлов в данном каталоге.
Но, даже, если он (список) не резидентный, то все равно, его "начало" резидентно.
Поэтому, я не понимаю исходя из ты противопоставляешь:
"NTFS использует B-tree организацию" и "какой номер записи"

>То что ты упоминаешь это файловые потоки, их может быть до 2^32 если правильно помю Руссиновича.
Эту фразу я совсем не поняла. Что имеется ввиду под "То что ты упоминаешь" ?
И какую роль играет то, сколько потоков у файла ?

tesseract (2007-06-24 12:28:00) [34]

> В общем случае, задача звучит так: по имени файла определить
> "номер записи в MFT".

> В MFT (NTFS) нет "прошитого" алгоритма сортировки :)

NTFS использует B-tree организацию, какой номер записи?. То что ты упоминаешь это файловые потоки, их может быть до 2^32 если правильно помю Руссиновича.

Германн (2007-06-24 03:14:00) [35]

> > [6] Германн © (24.06.07 02:34)
> >Следущая стадия вполне может оказаться стадией "Прогона
> Через Строй"!
> Это как в "царской" армии ?
> Сижу себе смирно. Никого не трогаю.

Ты ещё скажи "починяю примус"! :)

Riply (2007-06-24 03:01:00) [36]
Если кому интересно:
В MFT (NTFS) нет "прошитого" алгоритма сортировки :)
Она позволяет сортировать практически по любому параметру(набору параметров).
За тип сортировки отвечает параметр CollationRule из INDEX_ROOT структуры.
"A numeric identifier of the collation rule used to sort the index entries."
P.S.
Я конечно понимаю: гибкость системы и все такое...
Но надо же и меру знать ! :))

> [6] Германн © (24.06.07 02:34)
>Следущая стадия вполне может оказаться стадией "Прогона Через Строй"!
Это как в "царской" армии ?
Сижу себе смирно. Никого не трогаю. А тут "через строй" :)

Германн (2007-06-24 02:34:00) [37]

> Ну вот. Дожили. Ликвидированы последние остатки демократии.
> :)
> Теперь прогоняют даже из "начинающих" :)
>

Почти все стадии сего процесса ты уже прошла. Следущая стадия вполне может оказаться стадией "Прогона Через Строй"! Готова?
:)

Riply (2007-06-24 01:37:00) [38]
> [3] Dimaxx © (23.06.07 16:47)
>> MOUNP~1, tracking.log
>Лежат в папках SystemVolumeInformation
Спасибо.
Видимо, я пошла не тем путем :(
Можно, конечно, сказать про $-файлы и файлы из SystemVolumeInformation
что "это неправильные пчелы" (с) Винни и убрать их из рассмотрения :)
Но, мне не нравятся правила, в котроых есть исключения :).
Алгоритм существует. Просто обязан быть. Про него известно следующее:
Базовый принцип: минимальное количество обращений
к диску при поиске записи, соответствующей файлу.
Чем меньше "вложений" в имени файла,
тем меньше обращений к диску требуется системе для его нахождения.
Скорее всего я не там его ищу.
Видимо, есть еще какие-то характеристики, про которые я еще не знаю (пока не знаю :)
[2] Anatoly Podgoretsky © (23.06.07 12:38)
>Ну ты дала, нашла где задавать такой вопром, а ну бегом в WinAPI
Ну вот. Дожили. Ликвидированы последние остатки демократии. :)
Теперь прогоняют даже из "начинающих" :)

Dimaxx (2007-06-23 16:49:00) [39]

> NewNum меньше 30 имеют файлы типа: $ObjectID, $LogFile и
> т.п.

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

Dimaxx (2007-06-23 16:47:00) [40]

> MOUNP~1, tracking.log

Лежат в папках SystemVolumeInformation, по умолчанию к ней (и всему содержимому) имеет доступ тока сама винда. Хотя ничто не препятствует сделать до содержимого доступ себе... :)

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »