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

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

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

NtReadFile NtFsControlFile. Разница возвращаемых данных.

Страницы: 1 2 3 >
Riply © (2008-04-04 21:34:00)
Здравствуйте !
Давным давно я поднимала этот вопрос. Тогда ответа не нашли.
Может сейчас у кого-нибудь будут идеи, как объяснить(понять) следующий факт:

Читаем файловую запись двумя способами: NtReadFile и NtFsControlFile(..., FSCTL_GET_NTFS_FILE_RECORD, ...).
В первом случае получаем мусор, во втором корректные данные.
(какой именно FileRecord прочитала NtFsControlFile - проверяется).
Эффект довольно трудно, но воиспроизводим (я приводила диск в "непотребное" состояние :)

Когда я столкнулась с разницой между прямым чтением и чтении через API, подумла
что вот она - причина и списала этот вопрос на всевозможные "кеширования" и "буферизации".

Но сейчас, похоже, это объяснение не проходит.
Во всяком случае, эффект наблюдается (на тех одних и тех же файловых объектах)
как после длительной работы, так и сразу после холодного рестарта.

Очень бы хотелось понять происходящее. Кто что думает: какие могут быть причины ?

Riply (2008-04-05 23:30:00) [1]
> [43] guav © (05.04.08 23:25)
> А надо рассматривать группами по Clusters per Index Record из $INDEX_ROOT.

Даже и не знаю как объяснить, какое ОГРОМНОЕ СПАСИБО я тебе хочу сказать :)
Пойду проверять и переделывать код. Если сон не сморит :)
Спасибо !

guav (2008-04-05 23:25:00) [2]
> Я их рассматриваю группами по Count

А надо рассматривать группами по Clusters per Index Record из $INDEX_ROOT.

Riply (2008-04-05 23:20:00) [3]
Я их рассматриваю группами по Count

Riply (2008-04-05 23:19:00) [4]
> [40] guav © (05.04.08 23:14)
> Ага, таки понял.
> Ты рассматриваешь каждый Lcn отдельно и ищешь INDX в каждом.
> Это нверено, рассматривай весь аттрибут как целое.

А вот теперь я не поняла. Что ты имеешь ввиду ?

guav (2008-04-05 23:14:00) [5]
Ага, таки понял. Ты рассматриваешь каждый Lcn отдельно и ищешь INDX в каждом. Это нверено, рассматривай весь аттрибут как целое.

guav (2008-04-05 23:10:00) [6]
Уже понял, только не понял почему этот Lcn интерпретируется как файл-рекорд, если это чать $INDEX_ALLOCATION.

там будет сигнатура IDNX или не будет - в зависимости от того является ли он началом нового индекса или продолжением индекса начатого в предыдущем Lcn

Riply (2008-04-05 23:08:00) [7]
> [36] guav © (05.04.08 22:57)

Да знаю я первые два пункта :)

> 3. Даже если с 221120 не получилось как с частью индекса,
> на каком основании предпринимается попытка считать его частью MFT ??

Ни на каком. Он не валидный. Все последующие действия с ним
это ни что иное, как попытка понять откуда он такой у нас взялся, почему взялся,
с чем его едят, и где тогда нажодиться нужная нам информация ?

Riply (2008-04-05 23:02:00) [8]
> [33] guav © (05.04.08 22:38)
> Ну, а дальше? Где там LCNы, в частности 221120 ?

Вот примерный код, возвращающий Lcn`ы из RETRIEVAL_POINTERS_BUFFER
Среди них и 221120 :)

with pRetPointers^ do if ExtentCount > 0 then begin PrevVcn := StartingVcn.QuadPart; i := 0; while i < integer(ExtentCount) do with Extents[i] do begin aCount := NextVcn.QuadPart - PrevVcn; // Что то делаем, например парсим "индекс i, Lcn = Lcn, Count = aCount PrevVcn := NextVcn.QuadPart; inc(i); end; end;

guav (2008-04-05 22:57:00) [9]
1. Других MAGIC, кроме IDNX у :$I30:$INDEX_ALLOCATION не может быть.
2. Индексные структуры вообще-то обходятся по ссылкам в них, начиная с $INDEX_ROOT.
3. Даже если с 221120 не получилось как с частью индекса, на каком основании предпринимается попытка считать его частью MFT ??

Riply (2008-04-05 22:44:00) [10]
> [33] guav © (05.04.08 22:38)
> А какие другие Magic могут получится ?

Саш, я сейчас заплачу :)
Я ж тебе целый день толкую о том, что у этого (удалено модератором) 221120 - все не так. :)
Он не настоящий, а липовый :)
у него вообще Magic`а равен 12354, (если мне не изменяет память). Не занаю я таких Magic`ов.
Хоть бы нули там были что-ли.

Riply (2008-04-05 22:38:00) [11]
> [31] guav © (05.04.08 22:24)
> Кстати спёртый у линуксоидов скрывать вообще не надо, там же GPL.

А никто ничего и не скрывает.
Только там от оригинала остались разве что названия переменных да констант.
А все остальное искарежено вашей покорной слугой :)

guav (2008-04-05 22:38:00) [12]
> Когда, например, получаем MAGIC_INDX, воспринимаем это хозяйство
> как INDEX_BLOCK_HEADER,

А какие другие Magic могут получится ?

> и начинаем перебирать объекты, которые она описывает

Ну, а дальше? Где там LCNы, в частности 221120 ?

Riply (2008-04-05 22:35:00) [13]
> [29] guav © (05.04.08 22:01)
> Дело в том что в директории вообще не хранятся Lcnы содержащихся в ней файлов.

Да. Терминологоия у меня сильно страдает. Который раз замечаю.
Sorry.

Как все это получается:
Берем директорию, читаем ее атрибуты.
Из атрибута AT_INDEX_ALLOCATION получаем Run-ы.
"Декомрессируем" их и получаем вот этот наш километровый список Lcn-ов с одним бракованным :)
Начинаем их считывать и разбирать по косточкам.
Когда, например, получаем MAGIC_INDX, воспринимаем это хозяйство как INDEX_BLOCK_HEADER,
и начинаем перебирать объекты, которые она описывает. Это я и называю "файлами в директории" :)

guav (2008-04-05 22:24:00) [14]
> [28] Riply © (05.04.08 21:55)

Кстати спёртый у линуксоидов скрывать вообще не надо, там же GPL.

guav (2008-04-05 22:06:00) [15]
> Это Lcn`ы из INDEX_ALLOCATION атрибута директории

Стоп. Ты что ли получаешь Retriveal Pointers у :$I30:$INDEX_ALLOCATION директории и пытаешься в этих Lcn искать файлрекорды ?

guav (2008-04-05 22:01:00) [16]
> [28] Riply © (05.04.08 21:55)

Да любой.
Дело в том что в директории вообще не хранятся Lcnы содержащихся в ней файлов.

Riply (2008-04-05 21:55:00) [17]
> [26] guav © (05.04.08 21:44)
> Не верю. Приведи код получения Lcn.

Какой из двух ? "Спертый" у линуксоидов или через FSCTL_GET_RETRIEVAL_POINTERS ?

> таки откуда в директории взялись Lcnы её файлов,
> не перевела ли ты полученные из директории файлреференсы в Lcnы ?

Это Lcn`ы из INDEX_ALLOCATION атрибута директории

guav (2008-04-05 21:47:00) [18]
> при переборе Lcn-ов

таки откуда в директории взялись Lcnы её файлов, не перевела ли ты полученные из директории файлреференсы в Lcnы ?

guav (2008-04-05 21:44:00) [19]
> Это один из большого списка Lcn-ов, который так себя ведет.
> К тому же этот список я получала как "законным" способом,
> так и "своим".
> Они (списки) совпадают.

Не верю. Приведи код получения Lcn.

Riply (2008-04-05 21:43:00) [20]
> [23] guav © (05.04.08 21:36)
> Если я не ошибся в анализе твоих заблуждений,
> то то что ты хочешь найти в 221120 находится в 306221 :)

А это еще кто такой ?

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

Наверх

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