Fehler in DirectoryExists und UNC Pfade für XE

[yörsch]

Hallo Zusammen,

in XE funktioniert DirectoryExists für UNC Pfade nicht. Es wird immer True zurück gegeben!

Der Support empfiehlt
1) eine eigene MySysUtils unit zu erstellen und den Fehler darin zu fixen
oder
2) sich XE2 zu kaufen, da ist der Fehler behoben.

Beider Lösungen sind nicht akzeptabel.

Zu 1: Was ist mit all den Funktionen von in Delphi, die DirectoryExists weiterhin aus SysUtils verwenden.
Soll ich die auch gleich alle Fixen? :gruebel:

Zu 2: Auch schlecht wir haben erst diese Jahr auf XE umgestellt und nach einem ¾ Jahr wieder alles umstellen? Im Projektgeschäft ist OK; bei einem Produkt das das nicht so leicht möglich. Da sind die Zyklen größer. (so 3 - 6 Jahre für das gesamte FrameWork)

Den Code, der vom Support kommt, hab ich mal bereit gestellt. Da kann man sehen,
es ist nix aufregendes was das verändert werden muss.
Und ich hab mir mal FileExists angeguckt und den gleichen Fehler gefunden…
Der Support sagt das er sich weigert den Fehler zu Fixen.

Mein Frage:
Hat Ihr eine Möglichkeit die RTL150.bpl neu zu erzeugen?
oder gibt es einen anderen weg?

Gruß
Jörg

Code:

function DirectoryExists(const Directory: string; FollowLink: Boolean = True): Boolean; 
{$IFDEF MSWINDOWS} 
var
  Code: Cardinal;
  Handle: THandle;
  LastError: Cardinal;
begin
  Result := False;
  Code := GetFileAttributes(PChar(Directory));

  if Code <> INVALID_FILE_ATTRIBUTES then
  begin
    if faSymLink and Code = 0 then
      Result := faDirectory and Code <> 0
    else
    begin
      if FollowLink then
      begin
        Handle := CreateFile(PChar(Directory), GENERIC_READ, FILE_SHARE_READ, nil,
          OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0);
        if Handle <> INVALID_HANDLE_VALUE then
        begin
          CloseHandle(Handle);
          Result := faDirectory and Code <> 0;
        end;
      end
      else if faDirectory and Code <> 0 then
        Result := True
      else
      begin
        Handle := CreateFile(PChar(Directory), GENERIC_READ, FILE_SHARE_READ, nil,
          OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0);
        if Handle <> INVALID_HANDLE_VALUE then
        begin
          CloseHandle(Handle);
          Result := False;
        end
        else
          Result := True;
      end;
    end;
  end
  else
  begin
    LastError := GetLastError;
    Result := (LastError <> ERROR_FILE_NOT_FOUND) and
      (LastError <> ERROR_PATH_NOT_FOUND) and
      (LastError <> ERROR_INVALID_NAME) and
      (LastError <> ERROR_BAD_NETPATH);// <= Die entscheidende Zeile, die fehlte...
  end;
end;
{$ENDIF MSWINDOWS}
{$IFDEF POSIX}
var
  StatBuf, LStatBuf: _stat;
  LDirectory: UTF8String;
  Success: Boolean;
begin
  LDirectory := UTF8Encode(Directory);
  Success := stat(PAnsiChar(LDirectory), StatBuf) = 0;
  Result := Success and S_ISDIR(StatBuf.st_mode);

  if not Result and (lstat(PAnsiChar(LDirectory), LStatBuf) = 0) and
    S_ISLNK(LStatBuf.st_mode) then
  begin
    if Success then
      Result := S_ISDIR(StatBuf.st_mode)
    else if not FollowLink then
      Result := True;
  end;
end;
{$ENDIF POSIX}

[jbg]

Was soll der Blödsinn überhaupt mit der GetLastError Abfrage. Wenn GetFileAttributes INVALID_FILE_ATTRIBUTES liefert, dann existiert das Verzeichnis nicht. Da muss man nicht noch die ErrorCodes abprüfen und mit jeder neuen Windows Version vielleicht den Code anpassen weil es neue ErrorCodes gibt. Wer bei Embt ist denn auf den Unsinn gekommen? Mir leutet er zumindest im Moment nicht ein.

[DeddyH]

Zumal der ErrorCode ja nirgends zurückgegeben wird.

[Bernhard Geyer]

Zitat:

Zitat von yörsch (Beitrag 1132881)

Beider Lösungen sind nicht akzeptabel.

Zu 1: Was ist mit all den Funktionen von in Delphi, die DirectoryExists weiterhin aus SysUtils verwenden.
Soll ich die auch gleich alle Fixen? :gruebel:

Schau dir mal die TNTWar Kompos an. Dort gibt es Funktionen/Proceduren um Systemfunktionen zu überschreiben. Hab ich bei D6 im Einsatz um hier ein paar Fixes in der RTL einzubringen.

Zitat:

Zitat von yörsch (Beitrag 1132881)

Hat Ihr eine Möglichkeit die RTL150.bpl neu zu erzeugen?
oder gibt es einen anderen weg?

Geht nicht. Du musst wenn du Laufzeitpackages verwenden willst deine eigenen Stack von BPL's aufbauen. Bei MS kann ja auch keiner so mal die MFC/ATL patchen.

[yörsch]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1133042)

Schau dir mal die TNTWar Kompos an.

Eine alternative... wenn ich allein währe, aber wie konntrolliere ich über 30 Entwickler an mehren Standorten?
Und das Überarbeiten von einigen Mio.Zeilen Code nicht auch nicht ohne...

Auch die Geschichte mit der relativen nähe von Units hilft da nur begrenzt...

Code:

uses                                      
  SysUtils, ActnList,... , TntActnList, TntSysUtils;

Zitat:

Zitat von Bernhard Geyer (Beitrag 1133042)

Geht nicht. Du musst wenn du Laufzeitpackages verwenden willst deine eigenen Stack von BPL's aufbauen. Bei MS kann ja auch keiner so mal die MFC/ATL patchen.

Das ist nachvollziehbar, wie ich mir schon dachte...
Da muss wohl der Druck auf einige Endscheider bei Embacadero einwenig erhöht werden :feuerchen:

Danke für deine Anregungen!
Da sind echt einpaar neue Dinge, die Ich soauch noch nicht wusste....

[yörsch]

Zitat:

Zitat von jbg (Beitrag 1133007)

Was soll der Blödsinn überhaupt mit der GetLastError Abfrage. Wenn GetFileAttributes INVALID_FILE_ATTRIBUTES liefert, dann existiert das Verzeichnis nicht. Da muss man nicht noch die ErrorCodes abprüfen und mit jeder neuen Windows Version vielleicht den Code anpassen weil es neue ErrorCodes gibt. Wer bei Embt ist denn auf den Unsinn gekommen? Mir leutet er zumindest im Moment nicht ein.

Das war, wie schon gesagt, der Support.
Keine Ahnung wer genau, aber ich sehe nur die Auswirkungen...

[himitsu]

Gut, es mag Fehler geben, welche auf ein Problem hindeuten, aber dann hätte ich maximal noch eine Exception geworfen.

Aber wenn schon auf gewisse Fehler reagieren, dann doch auf diese Fehler prüfen und nicht die Gegenfehler, wie es Emba macht ... dann kommt mal wer und erfindet neue Fehler und :stupid:

[yörsch]

Zitat:

Zitat von himitsu (Beitrag 1133125)

Gut, es mag Fehler geben, welche auf ein Problem hindeuten, aber dann hätte ich maximal noch eine Exception geworfen.
Aber wenn schon auf gewisse Fehler reagieren, dann doch auf diese Fehler prüfen und nicht die Gegenfehler, wie es Emba macht ... dann kommt mal wer und erfindet neue Fehler und :stupid:

himitsu, da bin ich deiner Meinung! Und versuche so meine eigenen Fehlerchen in den Griff zubekommen...
Aber soll ich beim nächsten Zyklus der Produkte auf C# setzten oder was:?:
Das da einer bei Emba schlechten Tag hatte als der Code entstanden ist mag sein. Hilft mir auch nicht weiter...

[Bernhard Geyer]

Zitat:

Zitat von yörsch (Beitrag 1133122)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1133042)

Schau dir mal die TNTWar Kompos an.

Eine alternative... wenn ich allein währe, aber wie konntrolliere ich über 30 Entwickler an mehren Standorten?
Und das Überarbeiten von einigen Mio.Zeilen Code nicht auch nicht ohne...

Auch die Geschichte mit der relativen nähe von Units hilft da nur begrenzt...

Du hast mich mißverstanden. Du musst nur an einer Zentralen stelle für das aufruf einer "FixDxx"-Funktion sorgen.
Diese ersetzt dan Zentrale Funktionen in der RTL mit gefixten Versionen. Im restlichen Programm muss nix geändert werden.

[yörsch]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1133137)

Du hast mich mißverstanden. Du musst nur an einer Zentralen stelle für das aufruf einer "FixDxx"-Funktion sorgen. Diese ersetzt dan Zentrale Funktionen in der RTL mit gefixten Versionen. Im restlichen Programm muss nix geändert werden.

Hab ich da was überlesen??? Wo wird den das in TNTWar gemacht? Wo wird SysUtils überschrieben ?

Wie das Grundsätzlich mit Komponenten funzt ist mir auch klar.
Wir haben auch alles abgeleiten und eigene Dinge rein gemacht...
Aber
wenn einer Vergist MySuperSysUtils einzubinden und dann DirectoryExists aufruft
hab ich beim erkennen und suchen des Fehlers keine freude mehr ... :kotz:
Dazu ist das Produkt einfach zugroß und zuverteilt...

Wir arbeit mit Laufzeit Packages, das sollte erstmal keinen großen unterschied zur EXE machen...

Oder hab ich dich wirklich falsch verstanden ???

[CCRDude]

In der TntSystem.pas wird das gemacht. Aber natürlich nicht die ganze SysUtils, sondern einzelne Funktionen.

Da ich das schon für QC 45628 gemacht hatte, habe ich meinen entsprechenden Code auch mal um QC 92183 (dieser Bug) erweitern.

Nur - lässt sich so eine fertige Patch-Unit (die einmal irgendwo im Projekt eingebunden werden muss) überhaupt veröffentlichen? Gepatchte Funktionen unterliegen immerhin weiter dem Copyright von Embarcadero...

[yörsch]

Ich bin einwenig verwirt, Da hab ich einige Zeilen wirklich nicht verstanden...:gruebel:
und werd das jetzt mal intensiver Testen...
Wenn nach dem Einbau von TNTWar DirectoryExist sauber geht bin ich im Vorfeld schon mächtig beeindruckt...

[CCRDude]

TntWare einbauen bringt nichts; in TntSystem.pas aus den TntWare Controls steht nur der Trick drin, den Du anwenden musst.

Ich habe mal das Grundgerüst minus den gepatchten Teil diesem Post angehängt. Die Funktion DirectoryExistsQC92183 musst Du einfach mit dem Dir mitgeteilten Code füllen, dann die Unit einbinden (am besten - imho - in die .dpr).

[yörsch]

Ich hab das, ähnlich wie deine Lösung , mal aus dem großen UniCode System zusammen gestrichen
Und bin sehr erstaunt wie gut das geht. Toll :thumb:

Wenn mich nix täuscht,
ist das auch für alle Betriebssysteme unter WinDoof und Linux etc. brauchbar.

Wie gesagt, eine echt Tolle die Lösung, Jetzt kann jeder weitere Delphi Fehler leicht selbst korrigieren!

DICKES DANKE

[yörsch]

Hier noch meine getestete Lösung.

Vielen Dank an alle.

(*CLOSED*)

[tofse]

Super, vielen Dank, bin fast wahnsinnig geworden und gar nicht auf die Idee gekommen, dass es hier so einen offiziellen Bug geben könnte. Ich verstehe zwar nicht wirklich, was Ihr hier "gebaut" habt, aber nach einbinden der DelphiBugPatches.pas funktioniert alles, wie es soll :thumb: :thumb: :thumb: