Fehleranfääliges DirectoryExists auch in Delphi > XE 1?

[hathor]

An den TE:
Teste doch mal diesen Code aus XE2:
http://www.delphipraxis.net/1222644-post11.html

[jensw_2000]

Zitat von Uwe Raabe:

Zitat von Sir Rufo:

Soso, und wenn dieser Fehler da ist, dann ist es trotzdem ein existierendes Verzeichnis und der Rückgabewert muss true sein?

Ich meine schon. Schließlich existiert ja die Root des Share. Ob ich da reinschreiben kann ist wieder eine andere Frage.

Genau hier liegt der Hase im Pfeffer.
Die "Root des Shares" ist der Server bzw. die "DFS Farm", da kann man nie was hinschreiben. Es ist kein Ordner.
Das Share ist die Bezeichnung hinter dem Servernamen.

Also:
\\Server\ <<--- hier schreibt keiner was hin.
FileExists und DirectoryExists müssen fehlschlagen. Es kann auch kein "\\Server\." oder "\\Server\.." geben.

\\Server\Share\ <<--- hier schon (DirectoryExists muss klappen, wenn die Berechtigungen vorhanden sind)
\\Server\Share\SubDirectory\ <<--- da auch (DirectoryExists muss klappen, wenn die Berechtigungen vorhanden sind)
\\Server\Share\File <<--- hier ebenfalls (FileExists muss klappen, wenn die Berechtigungen vorhanden sind)
\\Server\Share\SubDirectory\File <<--- genau wie dort (FileExists muss klappen, wenn die Berechtigungen vorhanden sind)

[Uwe Raabe]

Zitat von jensw_2000:

Das Share ist die Bezeichnung hinter dem Servernamen.

Das ist aber auch genau das, was ich aus der MSDN-Doku unter network share verstanden habe.

[Sir Rufo]

Zitat von Uwe Raabe:

Zitat von jensw_2000:

Das Share ist die Bezeichnung hinter dem Servernamen.

Das ist aber auch genau das, was ich aus der MSDN-Doku unter network share verstanden habe.

Das will auch niemand bestreiten, allerdings ist die Frage ja auch ein ganz andere:

Zitat:

Soll DirectoryExists( '\\Server' ) tatsächlich ein true zurückliefern?

Klarer Fall: Nein, denn das ist kein Verzeichnis!

Eigentlich wäre es noch zu überlegen, ob hier nicht sogar eine Exception geworfen werden müsste, weil ja gar kein gültiger Verzeichnisname angegeben wurde, aber das verwirrt hier jetzt wohl mehr.

[samso]

Bei FileExists gibt/gab es ja eine ähnliche Abfrage. Dort hatte diese Abfrage den Sinn, im Fall einer gelockten Datei (z.b. ShareExclusiv) wieder zur alten Suche via FindFirst zurück zu fallen. Gibt es unter Windows die Möglichkeit ein Directory zu locken? Oder hat der Programmierer von DirectoryExists einfach zu viel Copy&Paste betrieben?

[Sir Rufo]

Nur so am Rande erwähnt, es gibt da z.B. den Fehler ERROR_INVALID_PASSWORD .

Angenommen es gibt ein Netzwerk-Device mit dem Namen Server und ich habe dort aber keine Berechtigung, dann liefert jede Abfrage DirectoryExists( '\\Server\KomischesVerzeichnisDasEsAuchEhNichtGibt\' ) ganz stumpf ein true zurück.

Insgesamt muss man den hier auch den Kontext betrachten. So liefert auch eine Abfrage auf \\.\COM1 oder \\.\COM1\ ein true zurück (wenn es einen Com-Port COM1 gibt) und ein \\.\COM5 oder \\.\COM5\ liefert ein false wenn es den Com-Port eben nicht gibt.

Ja, ist das denn nun ein Verzeichnis oder nicht?
Will ich diese Funktion dazu gebrauchen können auf einen Com-Port zu prüfen?

[hathor]

Zitat von samso:

Gibt es unter Windows die Möglichkeit ein Directory zu locken?

http://msdn.microsoft.com/en-us/libr...vs.100%29.aspx

[CCRDude]

Vielen Dank für die zahlreichen Antworten!
Die haben mich auf die richtige Fährte gebracht...

Tatsächlich geht es auf den Rechnern, wo das Problem auftritt, um Netzwerk-Pfade, war mir erst gar nicht bewusst, da es um den "Start Menu\Programs"-Ordner geht.

Habe mir nun entsprechend auch ein Testprogramm geschrieben, dass mir zu diversen Pfaden die Rückgabewerte ausgibt, und damit eure Beschreibung nachvollzogen. Werde den entsprenden Code jetzt umstellen auf FindFirst, damit habe ich das Problem anderswo schonmal in den Griff bekommen (aus anderem Grund umgestellt damals) und dann mittelfristig wohl doch mal auf XE 7 umsteigen.

[Sir Rufo]

Auch mit XE7 wird das nicht besser.

Einzige Lösung: Schreibe dir eine eigene DirectoryExists Funktion, die sich genau so verhält, wie du das erwartest. Und das geht auch ohne FindFirst .

Wie du die umsetzt ist egal, solange die genau das macht, was du davon erwartest

[CCRDude]

Mit XE 7 ist dieses Problem bereits behoben, habe ich ja direkt verglichen.

Wobei ich das Upgrade eher plane, weil diese Diskussion gezeigt hat, dass die RTL doch noch aktualisiert wird, nicht konkret für dieses Problem.

FindFirst war auch nur ein Platzhalter für eine wesenlich komplexere eigene Klasse, die Dateisysteminhalte ausliest und cacht (und nicht nur auf FindFirst, sondern auch Native-Zugriffen basiert und und ...). War nur an dieser Legacy-Code-Stelle noch nicht in Betrieb.