Mittwoch, 25. Februar 2009

Noch ein letztes Wort zu C:\Programme und C:\Program Files

Wer mein Blog liest, der weiß, dass ich mich über das Fehlverhalten des Windows Explorers unter Windows Vista als auch der aktuellen Beta von Windows 7 aufrege. Wie es aussieht, ist das ja alles so gewollt, und wir Deutsche müssen uns endlich abfinden, dass das eben nicht geht. (Oder doch nicht? Weiter unten ist die Lösung, für alle, die nicht weiterlesen möchten!)

Während meiner Tests habe ich die verschiedenen Sprachversionen noch einmal unter die Lupe genommen. Der übersetzte Begriff für Program Files kommt immer aus der desktop.ini:

[.ShellClassInfo]
LocalizedResourceName=
    @%SystemRoot%\system32\shell32.dll,-21781

In der shell32.dll steht an Position 21781 eben Programme, im Französischen wird der Text Programmes genommen.

Um das fehlerhafte Verhalten in den Deutschen Versionen zu erklären, muss man eine ältere Windows Version installieren, z.B. Windows XP. Bei Windows XP hat man das Programme Verzeichnis auch so benannt, also das lag so wirklich auf der Festplatte. Im Französischen wurde Program Files verwendet, der übersetzte Text kam aus der desktop.ini.

Mit Windows Vista wollte man nun den besseren Weg gehen, Verzeichnisse sollte sprachunabhängig sein. Da es aber noch einige Programme gibt, die z.B. beim Installieren hart-kodiert C:\Programme verwenden, hat man die sogenannten symbolischen Verknüpfungen eingeführt. Diese sollten andere Programme automatisch auf die richtigen Verzeichnisse oder Programme umlenken.

Folgende Fehler gibt es bei den symbolischen Verknüpfungen:

  • man kann im Windows Explorer nicht c:\Programme eingeben
  • ein .NET Programm lässt jeden Zugriff auf c:\Programme nicht zu, man erhält eine DirectoryNotFoundException: Ein Teil des Pfades “c:\Programme” konnte nicht gefunden wrden.
  • ein .NET Programm kann auch keine Dateien unter c:\Programme öffnen

Also, bei mir funktionieren die symbolischen Verknüpfungen nicht, oder ich habe den Sinn immer noch nicht verstanden.

Endlich eine Lösung

Endlich habe ich mich getraut, und c:\Programme über die Kommandozeile gelöscht. Bitte nicht über den Windows Explorer, denn sonst erwischt man das echte Verzeichnis c:\Program Files.

  • Start –> Ausführen und cmd.exe eingeben und mit Administratorrechten ausführen
  • rd c:\Programme löscht dann die Verknüpfung

Jetzt kann ich zwar keine alten Programme mehr verwenden, die direkt auf C:\Programme schreiben möchten, aber das will ich auch nicht.

Wer trotzdem den symbolischen Link braucht, kann diesen (wie auch eigene) mit folgendem Befehl wieder erstellen:

  • Start –> Ausführen und cmd.exe eingeben und mit Administratorrechten ausführen
  • ins Rootverzeichnis mit cd /D %systemdrive%\ wechseln
  • mklink.exe /J Programme “c:\Program Files” erzeugt eine dort als Verbindung deklarierte Verknüpfung
  • attrib +H c:\Programme versteckt diese Verknüpfung

Toll, nach dem manuellen Ausführen von mklink.exe gehen auch alle meine .NET Testprogramme richtig. Wo ist nur der Fehler, warum geht das auf einem sauberen Windows Vista nicht richtig? Ich werde wohl doch keine Ruhe geben, und gleich einen virtuellen PC basteln, Nr. 1098.

Wie immer gilt, dass ich keine Garantie übernehmen kann. Also, vielleicht vorher alles ordentlich sichern oder so.

Kommentare:

  1. Zum Ausführen muss die Konsole "Als Admininstrator" geöffnet und der Pfad sollte noch für die Quellverlinkung mit angegeben werden, es sei denn man steht schon im korrekten Vezeichnis, bei mir z.B.
    mklink.exe /J e:\Programme "e:\Program Files"
    Und tatsächlich danach gehts wie gewünscht. Wie gesagt ich denke das Problem kommt von der Umschaltung der Benutzerkontensteuerung und damit verhunzten Rechten.

    AntwortenLöschen
  2. Danke Dieter für den Hinweis, hab's geändert.

    Aber was meinst du mit "Umschaltung der Benutzerkontensteuerung"? Das geht doch nie?

    AntwortenLöschen
  3. Prinzipiell könnte man es über secpol.msc feintunen. Siehe [F1], Eingabe "Benutzerkontensteuerung". Habe mich auch immer geweigert bzgl. RTFM, aber die Vista-Windows-Hilfe ist wirklich *sehr* umfangreich.

    AntwortenLöschen
  4. Es hat nichts mit der Benutzerkontensteuerung zu tun, oder zumindest nichts mit deren an- und abschalten. Hab das nämlich hier bei mir noch nie gemacht und das gleiche Problem.

    AntwortenLöschen