MMF для этого не предназначен, и не сможет такого гарантировать.
Гарантия записи при смерти юзер процесса появляется после закрытия системного хэндла (HFILE).

Если нужно гарантировать - закрывайте файл (все хэндлы) и открывайте заново. По-другому мне неизвестно.

MMF был первоначально сделан для внутренних нужд Винды, и оптимизации там касаются в основном чтения.

Vizit0r,

а файл, меньше двух гигов, и не sparse?

В этом случае ММФ должен рулить, особенно если working set небольшой.
Работа с памятью намного привычнее и удобнее чем seek/read, и ММФ не требует загрузки всего файла в память.

Без ММФ, если вы выделите массив, и прочитаете туда весь файл чтоб получить удобства памяти, этот массив все равно будет участвовать в ММФ без вашего ведома, только не с первоначальным файлом, а с pagefile. И тогда может оказаться медленнее, т.к. выгрузка в pagefile требует запись на диск, а read-only MMF просто выкидывает старые страницы и читает их заново из оригинала.

Sparse file - это файлы с дырками, для которых не отведено место на диске. Например, в первом килобайте есть данные, в 100500 килобайте есть данные, а между ними нет ничего, и места на диске не занимает. Дырка при чтении даст нули, а при записи начнет аллокировать кластеры диска, или какие там у конкретной системы единицы аллокации.

Если у вас таких файлов нет, то это не ваш головняк. Фрагментация диска на работу ММФ не влияет, 200МБ позволяет легко работать хоть из 32-бит, хоть из 64

Вы безусловно знакомы с разными методами подсчета памяти, и знаете почему один процесс может запросить, и получить больше памяти чем присутствует на компьютере.

для ММФ немедленно выделяется виртуальное пространство (интервал адресов) из пространства процесса.
Сколько начально поднимается с диска, зависит от оптимизаций в конкретной версии винды, возможно где-то описано, я уже не помню.

Вы можете это легко проверить, применив ММФ к файлу больше, чем количество свободной физической памяти на компе.