>  [19] guav ©   (05.04.08 20:08)
> И более интересный вопрос - откуда взялось 221120 ?
Как откуда ? Мы об этом "сбойном" Lcn`е толко и говорим. :)

Просто, пока я не добралась до Delphi,
пыталась "на пальцах" показать, что я делала в программе для проверки.

> [20] Riply ©   (05.04.08 20:49)

Каким образом получено значение 221120 ?
Тебе приснилось что этот LCN соотвествует каким-то файлрекордам ?

"Подтверждение" вроде
> FileRefNumber := ((221120 - MftStartLcn) * BytesPerCluster)
> div BytesPerFileRecordSegment;

читается - не годится, т.к. формула предполагает то чего нету - непрерывность MFT.

Ещё раз, на всякий случай:
1. 221120 судя по R.P. $Mft не принадлежит MFT. Ошибка уже совершена когда это значение получено.
2. Формула, позволяющая получить из него номер в MFT - ошибочна.
3. Для нумерации файлов и файлрекордов LCN не используется, используется MFT_SEGMENT_REFERENCE.

Если я не ошибся в анализе твоих заблуждений, то то что ты хочешь найти в 221120 находится в 306221 :)

> [22] guav © (05.04.08 21:20)
> 1. 221120 судя по R.P. $Mft не принадлежит MFT.
Не принадлежит, учитывая фрагментированность. Если бы ее не было, то принадлежал бы.
Конечно это мало что значит, но всеже.
> Ошибка уже совершена когда это значение получено.
Это один из большого списка Lcn-ов, который так себя ведет.
К тому же этот список я получала как "законным" способом, так и "своим".
Они (списки) совпадают.
> 2. Формула, позволяющая получить из него номер в MFT - ошибочна.
Это не формула (как формула, она конечно ошибочна) а только
описание того что я с ним, кроме всего прочего, пыталась делать.
> 3. Для нумерации файлов и файлрекордов LCN не используется, используется MFT_SEGMENT_REFERENCE.
Это я знаю, но какого черта, если на него посмотреть
как на MFT_SEGMENT_REFERENCE, то получим то что нужно ?

Попробую еще раз описать, что происходит:
Сканируется "подпорченый" диск.
На директории, описание которой выше, при переборе Lcn-ов
на Lcn равным 221120 спотыкаемся (считываемая структура не валидна).
Начинаем изучать этот чертов 221120-ый. Почему именно на нем и чем он отличается от других ?
В ходе этого дела, выясняется, что если предпринять попытки из [18]
то мы получаем именно то, что и должны были получить, если бы этот LCN
"считывался" так же как и все остальные его собратья :)

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

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

> Это один из большого списка Lcn-ов, который так себя ведет.
> К тому же этот список я получала как "законным" способом,
> так и "своим".
> Они (списки) совпадают.

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

> при переборе Lcn-ов

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

> [26] guav ©   (05.04.08 21:44)
> Не верю. Приведи код получения Lcn.

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

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

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

> [28] Riply ©   (05.04.08 21:55)

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

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

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

> [28] Riply ©   (05.04.08 21:55)

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

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

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

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

> Когда, например, получаем MAGIC_INDX, воспринимаем это хозяйство
> как INDEX_BLOCK_HEADER,

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


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

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

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

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

>  [33] guav ©   (05.04.08 22:38)
> А какие другие Magic могут получится ?

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

1. Других MAGIC, кроме IDNX у :$I30:$INDEX_ALLOCATION не может быть.
2. Индексные структуры вообще-то обходятся по ссылкам в них, начиная с $INDEX_ROOT.
3. Даже если с 221120 не получилось как с частью индекса, на каком основании предпринимается попытка считать его частью MFT ??

> [33] guav ©   (05.04.08 22:38)
> Ну, а дальше? Где там LCNы, в частности 221120 ?

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

> [36] guav ©   (05.04.08 22:57)

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

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

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

Уже понял, только не понял почему этот Lcn интерпретируется как файл-рекорд, если это чать $INDEX_ALLOCATION.

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