Как переместить CSC виртуальной машины Windows 7 на том сети / хоста?

306
ebsf

Я использую виртуальную машину Windows 7 Pro на VMware в Ubuntu 14.04 и хочу переместить CSC Win7 (кэш на стороне клиента для автономных файлов) в раздел данных на хосте Linux. Это локальный том, но Windows рассматривается как сетевой том.

Доступные онлайн-ресурсы предлагают два метода, ни один из которых (как реализованный) пока не работает.

Первый метод отключает автономные файлы, удаляет C: \ Windows \ CSC и его подкаталоги, создает соединение каталогов с новым местоположением и повторно включает автономные файлы. Этот метод завершается ошибкой, поскольку соединение каталога может ссылаться только на локальный том, а CSC не перестраивается при использовании символической ссылки каталога на том хоста (mklink / d вместо mklink / j).

Второй метод очищает CSC, затем создает HKLM / System / CurrentControlSet / Services / CSC / Parameters / CacheLocation = [целевой каталог]. Это предотвращает перезагрузку Win7. [Хорошо, что это была только виртуальная машина, которую я мог клонировать несколькими щелчками мыши.]

Итак, вопрос в том, возможно ли и как перенести CSC виртуальной машины Windows 7 Pro на том хоста. Любые мысли будут с благодарностью.

0

1 ответ на вопрос

0
Wes Sayeed

Я никогда не пробовал это, но я сильно подозреваю, что это не может быть сделано.

Инструменты VMWare внутри ВМ «фальсифицируют» сетевой доступ к хосту, о чем свидетельствует тот факт, что вы все равно можете получить доступ к хосту (через путь UNC), даже если у виртуальной машины нет доступа к сети.

CSC.sys - системный драйвер низкого уровня, который находится на том же уровне, что и сетевой стек. Я подозреваю, что он загружается первым, чтобы он мог делать свое дело, и он достаточно умен, чтобы знать разницу между локальным томом и сетевым путем (даже «поддельным»), поскольку в этом весь смысл его существования. Предполагается, что местоположение кэша является местом гарантированного доступа в случае сбоя сети. Параметр существует только для размещения его на другом локальном томе в случае ограниченного пространства диска C :.

Размещение кеш-памяти на сетевом диске (даже фальшивом VMWare) приведет к разрыву в пространственно-временном континууме с точки зрения ОС. Вероятно, именно поэтому Windows не загружается при попытке. Никто бы не подумал исправить эту ошибку, поскольку она не имеет смысла (в конце концов, вы можете теоретически изолировать гостя и / или удалить VMWare Tools, и вы также потеряете доступ к томам хоста).

Кроме того, соединения NTFS не так надежны, как жесткие ссылки * nix и символические ссылки. Есть много программ, которые не одурачены ими. Даже Windows Explorer не знал, что с ними делать до выхода Windows Vista, и единственная причина, по которой это удалось исправить, заключалась в том, что Microsoft начала использовать их для совместимости с Windows XP.

Если вам действительно удастся как-то сделать эту работу, я бы хотел знать, как вы это сделали.

Уэс, я подозреваю, что ты прав, что этого нельзя сделать. Я не разбираюсь в архитектуре Windows, но у меня есть интуиция к культуре проектирования и разработки Microsoft, которая, кажется, развивается в относительно узких предположениях о юзабилити, а не в более общих или надежных. На ум приходит множество примеров (службы терминалов; язык макросов Office, особенно в Excel и Access; отсутствие кодов раскрытия в Word; NTFS3). ebsf 9 лет назад 0
Таким образом, нетрудно представить, что что-то настолько элементарное, должно в корне конфликтовать либо с Windows (так, чтобы оно не загружалось), либо выходить за пределы возможностей NTFS. ebsf 9 лет назад 0
Я ожидаю, что решение для удаленной синхронизации файлов состоит в том, чтобы сделать это на локальном хосте Linux (а не на гостевой Windows), с rsync или Unison и Cygwin на удаленных машинах Windows. ebsf 9 лет назад 0