У меня возникло желание перенести файл hiberfil.sys в который сохраняется состояние памяти при переходе компьютера в спящий режим на другой раздел. В самом деле, на моём ASUS eee PC 4G встроенной памяти 4 Гб. Пока объём оперативной памяти - 512 Мб это ещё терпимо, но вот если решу увеличить её объём до 2 Гб - прощай спящий режим. А в ждущем режиме этот нетбук отвратительно быстро садит батарею. В то же время в кардридер вставлена карта памяти SHDC class 6 8Gb - быстрая и ёмкая. Я изучил возможность перенести образ системы для спящего режима на карту памяти и выяснил немало интересного.

В Windows NT (2000, XP, 2003, 7) имеется некоторое количество файлов, которые всегда находятся в корне диска C:\ Это boot.ini, NTLDR, NTDETECT.COM и hiberfil.sys. Последний файл я и намереваюсь перенести на отличный от диска C:\ раздел. Все эти файлы имеют непосредственное отношение к самым первым стадиям загрузки операционной системы, о чём можно судить уже по их именам. На сегодняшний день, все эти файлы невозможно хранить где-либо, кроме корневого раздела загрузочного диска и объясняется это просто. Чтобы загрузить эти файлы в память, когда происходит загрузка операционной системы уже необходим драйвер файловой системы. Но сам драйвер файловой системы хранится на диске и его невозможно прочитать, пока не приступит к работе драйвер файловой стистемы. Так что загрузка Windows (да и других операционных систем) явно похожи на попытку вытянуть самого себя за волосы из болота.

Этот порочный круг разрывается при участии маленького и простого драйвера файловой системы встроенного в первичный загрузчик. Этот драйвер умеет очень мало, он только находит файлы в корневом каталоге и загружает их в память. А те файлы, которые он загружает уже инициируют полноценную загрузку ОС, в том числе загружается полноценный драйвер файловой системы, который уже умеет находить из загружать файлы из разных подкаталогов и других дисков.

Со спящим режимом дела обстоят аналогично. При переходе в спящий режим всё содержимое оперативной памяти компьютера просто записывается в один файл. При выходе из спящего режима процесс обратный - файл просто копируется в память целиком. И проблема здесь аналогичная, чтобы загрузить hiberfil.sys требуется драйвер файловой системы, который целиком находится в hiberfil.sys. Поэтому его считывание в память обеспечивается тем же миниатюрным драйвером файловой системы, который инициирует начальную загрузку операционной системы.

Такая же ситуация была ещё во времена MS DOS (и прочих DOS тоже). Единственный файл SYS в корне файловой системы превращал обычную дискету в загрузочную. Причём при попытке сделать загрузочную дискету из обычной, на которую уже были записаны файлы вполне могла оказаться неудачной. Старые версии MS DOS требовали, чтобы загрузочные файлы находились в строго определённых участках файловой системы, чтобы загрузочный сектор мог найти их. В более поздних версиях загрузчик стал более интеллектуальным и уже мог находить загрузочные файлы где угодно при условии их размещения в корневом каталоге дискеты.

Итак, миниатюрный драйвер файловой системы не позволяет перемещять загрузочные файлы, в том числе и hiberfil.sys куда либо из корневого каталога. Он просто слишком прост, он ничего не знает про физические и логические разделы диска, файловые ссылки (линки), подкаталоги и т.п. высокоуровневую хрень. Предсавьте что этот загрузчик - не особо умный грузчик, которому поручили принести со склада два ящика. Он заходит на склад, обводит его мутным взглядом и не найдя нужных контейнеров возвращается назад. Ему не объяснить, что контейнер на другом складе, или что он находится на верхних полках и нужно подогнать вон тот электрокар и просто снять его, это бесполезно.

Если я теперь расширю память нетбука мне придётся отказаться от спящего режима. Или опять рассматривать возможность установки Linux, т.к. там процесс загрузки несколько отличается от принятого в Windows и есть возможность размещать дамп памяти при переходе в спящий режим на физическом подразделе отличном от загрузочного.

/ Создано с использованием материалов http://Technet.microsoft.com /