MS>>P.S.
MS>>По-моему такой подход (использование мега буффера) неправильный, потому как можно иметь достаточно небольшой буффер для retieval points и получать описание фрагментов порциями.


SO>а что вы можете мне посоветовать в решении моей проблемы, либо что мне передать в ClusterCount используя даный код, либо что вы мне посоветуете переделать или дописать в даном коде (что был в ссылке)?

Честно говоря нет никакого желания изучать код по ссылке.

Перемещать можно порциями кратными 16 кластерам:
— Больше шансов отработать FSCTL_MOVE_FILE успешно (ведь с момента, когда вы нашли свободный фрагмент до момента когда начнет отрабатывать FSCTL_MOVE_FILE этот фрагмент может уже перестать быть свободным, а чем больше размер перемещаемого фрагмента, тем больше шансов на такой случай)
Однако если вам удалось залочить том, то можете двигать любыми порциями, однако помните о том, что если вы синхронно ждете завершения операции, то время отклика (на Cancel) может стать неприлично большим.
— Работает и на сжатых файлах
— Если при запросе retieval points StartingVcn кратен 16, то в выходном буффере точки будут начинаться именно с заданного Vcn (Если StartingVcn не кратно 16, то в выходном буффере возможно округление вниз StartingVcn до кратности 16 или 8)
— Можете вообще не пользоваться FSCTL_GET_RETRIEVAL_POINTERS, а пользоваться FSCTL_GET_NTFS_FILE_RECORD и парсить retieval points вручную (так делает dfrgntfs, входящий в состав Windows 2000).

Итого:
Используя мега буффер алгоритм обработки retrieval points упрощается.
Если ваша программа не предназначена для серверов, то решение вполне уместное.