Текущий архив: 2007.09.02;
Скачать: CL | DM;
Вниз
MFT и чтение "неправильных" записей. Найти похожие ветки
← →
Riply © (2007-08-11 16:21) [0]Здравствуйте !
Может получиться так (такого эффекта удалось добиться изменением
размера диска при помощи Magic Partition v. 8.0),
что MFT будет содержать записи со следующими интересными свойствами:
Допустим мы неким(любым) способом получили ObjUsn - порядковый номер объекта в MFT.
И мы уверены в его корректности.
Чтобы эксперимент был чистым, после его получения отсекаем sequence number:
ObjUsn := ObjUsn and $FFFFFFFFFFFF;
Получаем абсолютную позицию: AbsPos := _UsnToAbsPosition(ObjUsn);
Теперь пытаемся прочитать эту запись с помощю SetFilePointerEx и ReadFile
и выясняем, что по указанному адресу пусто (все забито нулями) или записан мусор.
Теперь пробуем получить эту запись через
DeviceIoControl(hVolume, FSCTL_GET_NTFS_FILE_RECORD, ....
поместив в NTFS_FILE_RECORD_INPUT_BUFFER наш ObjUsn.
После этого проверяем, что DeviceIoControl нам вернула запись именно того
объекта, который мы запрашивали:
FileID := PNTFS_FILE_RECORD_OUTPUT_BUFFER(pOutBuf).FileReferenceNumber.QuadPart;
if (FileID and $FFFFFFFFFFFF) = ObjUsn then...
Все совпадает, кроме одного:
в PNTFS_FILE_RECORD_OUTPUT_BUFFER(pOutBuf).FileRecordBuffer мы находим не
мусор, а корректную запись MFT-объекта,
причем именно того, чей ObjUsn мы ей передавали.
Каким образом DeviceIoControl находит "правильную" запись для конкретного адреса ?
P.S.
Сдвигаться вверх, в поисках нужной записи не подходит: можно получить не ту :)
← →
Lacmus © (2007-08-11 17:37) [1]Здесь уже были ?
http://www.linux-ntfs.org/
← →
Riply © (2007-08-11 17:49) [2]> [1] Lacmus © (11.08.07 17:37)
>Здесь уже были ?
Угу.
Они не заложили в свой Ntfs-3g проверку на последствия работы PM :)
Или я плохо искала :)
← →
Lacmus © (2007-08-11 18:28) [3]>Riply
Видимо для Вас не составит труда написать тестовый пример указанной проблемы
Страницы: 1 вся ветка
Текущий архив: 2007.09.02;
Скачать: CL | DM;
Память: 0.47 MB
Время: 0.025 c