areiland schrieb:
Nein, nein und abermals nein!
Erm, nur der Vollständigkeit halber: das kategorische Nein mag zwar im speziellen für den Windowsordner selber stimmen, aber nicht pauschal und insbesondere auch nicht aus dem verlinkten Grund.
Jedenfalls dann nicht, wenn man Reparsepoints nutzt, bzw Symlinks auf die Gerätepfade setzt. Die sind von Laufwerksbuchstaben unabhängig und jedes Windows, wenn es erstmal läuft, kann damit was anfangen. Sogar ntfs-3g kann damit umgehen und das hat nie was von Laufwerksbuchstaben gehört.
Natürlich muß man aufpassen und den richtigen Verknüpfungstyp wählen. Bei Windows nennen die sich Junctions und umfassen Mountpoints von Geräten an Ordnerpfaden einerseits und explizite Junctions von einem Ordnerpfad zum anderen andererseits (dafür gabs unter XP junction.exe und inzwischen mklink mit der Option /J).
Hardlinks funktionieren nicht (/H) wegen "Ordner", nicht "Datei im selben Volume" und Ordner-Symlinks (/D) funktionieren auch nicht (dort wird tatsächlich der hinterlegte Dateipfad verwendet wie bei einem "normalen" Symlink).
ALLERDINGS:
Windows arbeitet intern extensiv mit Hardlinks, allen voran via WinSXS; entsprechend muß der Pfad /Windows/WinSXS auf demselben Volume liegen wie ALLE Dateien, die in die Windowsinstanz selber geschrieben werden müssen. Entsprechend ist die Option, Unterordner von /Windows zu "exportieren", faktisch ausgeschlossen und der Rest zumindest fragwürdig. Grad kein Windows hier, aber ich bin mir fast 100% sicher, daß auch zB der Internet Explorer als Package unter WinSXS vermerkt ist... und aber nach /Program Files und /Program Files (x86) verlinkt wird.
Was natürlich grundlegend schief geht, wenn diese sich auf anderen Volumes befinden.
Was im Endergebnis auch nichts anderes bedeutet, daß "Windowsinstanz auf verschiedene Pfade verteilt" buchstäblich auf eigenes Risiko läuft. Kann gehen - muß aber nicht.
Wird einem auf die Nase fallen, wenn man unbedacht rangeht, und weil das von Microsoft nie so vorgesehen war, wird man auch mit unbrauchbaren Fehlermeldungen bedacht werden und eine Weile brauchen, um konkrete Probleme auf die Split-Volume-Architektur zurückzuführen.
Da reden wir noch nicht vom nächsten Upgrade auf einen späteren Windowsbuild. Instanz ab nach /Windows.OLD und los? Ja... äh... eher nicht.
Probleme gibts, zuhauf, erwartet und unerwartet; aber nicht wegen den Laufwerksbuchstaben.