TDirectory.GetFiles und ('C:\Documents and Settings')

[Harry Stahl]

Warum liefert mir das Programm beim Aufruf:

var files := TDirectory.GetFiles('C:\Documents and Settings'); die Fehlermeldung zurück, dass das genannte Verzeichnis (unter Windows) nicht bestehen würde?

OK, das Verzeichnis ist versteckt, aber daran sollte es doch nicht scheitern, oder?

Zumal mir in

var dirs := TDirectory.GetDirectories('C:\'); auch das Verzeichnis "C:\Documents and Settings" im Ergebnis (also im Dirs-StringArray) zurückgeliefert wird.

Das gleiche Problem tritt mit "C:\Dokumente und Einstellungen" auf.

Ferner das gleiche Problem mit

var attr := TDirectory.GetAttributes('C:\Documents and Settings', false); Ist das ein Bug oder habe ich hier etwas falsch verstanden?

[Harry Stahl]

OK, ich denke, das hat wohl etwas damit zu tun, dass in den neueren Windows-Systemen grundsätzlich kein Zugriff mehr darauf erlaubt ist.

Selbst wenn ich im Windows-Explorer mir versteckte Verzeichnisse anzeigen lasse und dort auf "Documents and Settings" doppelt klicke, erhalte ich den Zugriff verweigert Hinweis.

Konsequenz ist also, letztlich, im Suchfilter für Verzeichnisse im Laufwerk "C:\" diese beiden Ordner herauszufiltern, da man damit ja eh nichts anfangen kann...

[BerndS]

Komisch, bei mir ist das ein LINK und kein Verzeichnis. (Windows 10)
Diese LINK zeigt auf C:\Benutzer

[Frickler]

Unter Windows Vista aufwärts ist das ein virtuelles Verzeichnis. Das existiert nicht wirklich und wird von Windows nur simuliert aus Kompatibilität zu Windows XP und 2000.

[Uwe Raabe]

Zitat von Harry Stahl:

var attr := TDirectory.GetAttributes('C:\Documents and Settings', false);

Da es sich wie schon erwähnt um einen Link und nicht um ein echtes Verzeichnis handelt, funktioniert TDirectory.GetAttributes nur dann, wenn man den FollowLink-Parameter auf True setzt.

Für die anderen Methoden musst du erst über FileGetSymLinkTarget den wahren Namen des verlinkten Verzeichnisses herausfinden.

[himitsu]

@Frickler: Ja, ganr früher waren die Verzeichnisse oft direkt übersetzt vorhanden, in der Installationssprache des Windows.
Inzwischen ist, seit Jahren die Pfade immer in englisch, mit Translation in der "Anzeige" und oft auch mit zusätzlichen Junktions, falls jemand wirklich mal das "Sichtbare" benutzt.
Und auch die partition C: und das Windows-Verzeichnis heißen nun auch immer so (früher wurden die Partitionen gezählt und die 2. Partition war dann das D
Aber da zuviele Programmierer ständig schlampig mit hartgecodeten Pfaden arbeiteten, anstatt Windows zu fragen, ..........

Zitat von BerndS:

Komisch, bei mir ist das ein LINK und kein Verzeichnis. (Windows 10)
Diese LINK zeigt auf C:\Benutzer

du meinst bestimmt C:\Users

Jupp, einige Verzeichnisse sind auch oft doppelt.
* einmal das Original, inkl. Translation aus Desktop.ini
* und nochmal "unsichtbar" in der Übersetzung, als Junktion (funktionierend oder nicht), damit es umgeleitet wird, oder knallt, falls jemand wirklich die Übersetzung in einem Programm benutzt.

[Uwe Raabe]

Zitat von Harry Stahl:

Selbst wenn ich im Windows-Explorer mir versteckte Verzeichnisse anzeigen lasse und dort auf "Documents and Settings" doppelt klicke, erhalte ich den Zugriff verweigert Hinweis.

Das hat eher was mit den auf dem jeweiligen System erteilten Rechten des aufrufenden Benutzers zu tun. Als Administrator kannst du da schon was sehen.

Einfach nur diese Verzeichnisse auszuschließen löst das Problem nur halb, da du beim tatsächlich dahinter steckenden C:\Users ja auch keinen Zugriff hast.

[Stevie]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

var attr := TDirectory.GetAttributes('C:\Documents and Settings', false);

Da es sich wie schon erwähnt um einen Link und nicht um ein echtes Verzeichnis handelt, funktioniert TDirectory.GetAttributes nur dann, wenn man den FollowLink-Parameter auf True setzt.

Das ist leider nicht richtig - C:\Documents and Settings gibt es schon ab Windows Vista nicht mehr und es ist auch kein link.

Und bevor jetzt jemand sagt, jaaa, aber das was darunter liegt (also <username>/etc) liegt ja nun auf C:\Users\... - ja, das ist vielleicht der Default, aber man kann alle möglichen Folder (Documents, Downloads, Pictures, etc) an eine andere Stelle legen. Um diese herauszufinden gibt es SHGetFolderPath.

Wo die diversen virtuellen Verzeichnisse hinzeigen, kann man auch in der Registry sehen, unter

Code:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

[KodeZwerg]

Zitat von Stevie:

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

var attr := TDirectory.GetAttributes('C:\Documents and Settings', false);

Da es sich wie schon erwähnt um einen Link und nicht um ein echtes Verzeichnis handelt, funktioniert TDirectory.GetAttributes nur dann, wenn man den FollowLink-Parameter auf True setzt.

Das ist leider nicht richtig - C:\Documents and Settings gibt es schon ab Windows Vista nicht mehr und es ist auch kein link.

Wenn man ein englisch/amerikannisches Windows hat, hat es auch einen "C:\Documents and Settings" reparse point.

[Stevie]

Zitat von KodeZwerg:

Wenn man ein englisch/amerikannisches Windows hat, hat es auch einen "C:\Documents and Settings" reparse point.

Stimmt, die junction gibt es zwar, aber leider führt sie zumindest bei meinem Windows 10 ins nirgendwo:

Code:

C:\>cd "Documents and Settings"

C:\Documents and Settings>dir
 Volume in drive C is Windows
 Volume Serial Number is DA0A-6171

 Directory of C:\Documents and Settings

File Not Found

C:\Documents and Settings>

Und auch trotz FollowLink = True liefert TDirectory.GetAttributes eine Exception, da der intern aufgerufenen CheckGetAttributesParameters dieser Parameter herzlich egal ist.

Guckst du hier: https://superuser.com/questions/4583...es-it-point-to

Nur in Verbindung mit einem entsprechenden Unterordner bekommt man irgendwelche nützlichen Ergebnisse - z.b. wenn ich das hier mache:

Code:

C:\>cd "Documents and Settings"\sglienke

C:\Documents and Settings\sglienke>dir
 Volume in drive C is Windows
 Volume Serial Number is DA0A-6171

 Directory of C:\Documents and Settings\sglienke

17.02.2023  15:01    <DIR>          .
17.02.2023  15:01    <DIR>          ..
31.01.2023  10:37    <DIR>          .dotnet
02.02.2023  08:07    <DIR>          .nuget
11.01.2023  10:57    <DIR>          .templateengine
17.02.2023  15:01    <DIR>          .vscode
02.12.2022  08:33    <DIR>          3D Objects
02.12.2022  08:33    <DIR>          Contacts
20.02.2023  09:53    <DIR>          Desktop
23.01.2023  12:13    <DIR>          Documents
...