Wie verschieben Sie die CSC einer Windows 7-VM auf ein Netzwerk- / Host-Volume?

348
ebsf

Ich verwende eine virtuelle Windows 7 Pro-Maschine unter VMware unter Ubuntu 14.04 und möchte die CSC (clientseitigen Cache für Win- dows-Dateien) von Win7 auf die Datenpartition auf dem Linux-Host verschieben. Dies ist ein lokales Volume, wird jedoch von Windows als Netzwerkvolume betrachtet.

Die verfügbaren Online-Ressourcen weisen auf zwei Methoden hin, von denen keine (wie implementiert) noch zu funktionieren scheint.

Die erste Methode deaktiviert Offlinedateien, löscht C: \ Windows \ CSC und seine Unterverzeichnisse, erstellt eine Verzeichnisverknüpfung am neuen Speicherort und aktiviert Offlinedateien erneut. Diese Methode schlägt fehl, da eine Verzeichnisverknüpfung nur auf ein lokales Volume verweisen kann und CSC nicht neu erstellt wird, wenn stattdessen eine symbolische Verzeichnisverbindung zum Host-Volume verwendet wird (mklink / d statt mklink / j).

Die zweite Methode löscht die CSC und erstellt dann HKLM / System / CurrentControlSet / Services / CSC / Parameters / CacheLocation = [Zielverzeichnis]. Dies verhindert, dass Win7 neu gestartet wird. [Gut, dass es nur eine virtuelle Maschine war, die ich mit ein paar Mausklicks erneut klonen konnte.]

Die Frage ist also, ob es möglich ist und wie die CSC einer virtuellen Windows 7 Pro-Maschine auf das Volume eines Hosts verschoben werden kann. Alle Gedanken wären sehr dankbar.

0

1 Antwort auf die Frage

0
Wes Sayeed

I've never tried this, but I strongly suspect it cannot be done.

The VMWare Tools inside the VM "fake" network access to the host as evidenced by the fact that you can still access the host (via a UNC path) even if the VM doesn't have network access.

CSC.sys is a low-level system driver that sits at the same level as the network stack. I suspect it loads first so it can do it's thing, and it's smart enough to know the difference between a local volume and a network path (even a "faked" one), since that's the whole point of its existence. The cache location is supposed to be a place of guaranteed access in the event of a network outage. The parameter exists only to place it on a different local volume in the case of a space-constrained C: drive.

Placing the cache location on a network drive (even a faked VMWare one) would be ripping a hole in space-time continuum as far as the OS is concerned. This is probably why Windows won't boot when you try. No one would've thought to correct that bug since it makes no sense (after all, you could theoretically isolate the guest and/or uninstall the VMWare Tools and you'd lose access to the host's volumes as well).

Also, NTFS junctions are not as robust as *nix hardlinks and symlinks are. There are lots of programs that aren't fooled by them. Even Windows Explorer didn't know what to do with them before Windows Vista came out, and the only reason that got fixed was because Microsoft started using them for compatibility with Windows XP.

If you actually manage to make that work somehow I'd love to know how you did it.

Wes, ich vermute, du hast recht, dass das nicht geht. Ich verstehe nicht die Windows-Architektur, habe aber eine Intuition für die Microsoft-Design- und -Entwicklungskultur, die sich scheinbar zu relativ engen Vermutungen der Benutzerfreundlichkeit entwickelt, anstatt sich allgemeiner oder robuster zu verhalten. Man denke an eine ganze Reihe von Beispielen (Terminaldienste; Office-Makrosprache, insbesondere in Excel und Access; Fehlen von Reveal-Codes in Word; NTFS3). ebsf vor 9 Jahren 0
Daher ist es nicht schwer sich vorzustellen, dass etwas so Grundsätzliches entweder mit Windows in Konflikt steht (also nicht booten würde) oder über die Möglichkeiten von NTFS hinausgeht. ebsf vor 9 Jahren 0
Ich gehe davon aus, dass die Lösung für die Remote-Dateisynchronisierung auf dem lokalen Linux-Host (und nicht auf dem Windows-Gast), Rsync oder Unison und Cygwin auf Remote-Windows-Computern ausgeführt wird. ebsf vor 9 Jahren 0