Fehler bei FileExists

[six1]

Hi,
nachdem ein Programm von mir mit FileExists eine Datei als "Nicht vorhanden" bewertet hat, ging der Schlamassel los...
Bei FileExists sucht wohl jeder den Fehler irgendwo, aber NIEMALS im eigenen Programm! Nie... Nicht!
Tatsächlich zeigt der Explorer diese Datei in einer Share aber an... nichts außergewöhnliches an der Datei zu entdecken.
Zugriffrechte stimmen, ich kann die Datei auch mit Notepad++ öffnen und einsehen; alles so, wie es soll.
Ok, ich habe natürlich eine Kopie dieser Datei und bügle die einfach mal drüber und... mein Programm funktioniert wieder mit FileExists!

Ok, geht ja wieder. Entdeckt habe ich nichts, aber Erfolg zählt.
Nächster Tag:
FileExists kollabiert wieder und meint, die Datei gibt es nicht ... es war dann mittlerweile Tag drei, an dem die Anwender diese Datei, eine Reportdatei, nicht aufrufen konnten und damit nichts ausdrucken. Ich war langsam "leicht" unter Druck

Ich habe dann doch mal leicht gezweifelt und mit Hilfe von Google dies gefunden:
https://forum.lazarus.freepascal.org/in ... 55.15.html

Aha... gibts also doch, dass es vielleicht an "mir" liegen könnte...

Verzeichnis erstellt, fpcupdeluxe reingelegt und Laz 2.0.10 mit Fpc 3.2.1 installieren WOLLEN!
Wollt nicht. War ja klar. fpcupdeluxe meint, dass es Probleme gibt und abbrechen muss.
Also irgendwie war mir das schon fast klar; wenn es mal drauf an kommt...

ok, Plan B:
Laz 2.0.8 mit fpc 3.0.4 aufgerufen, Projekt von meinem Programm geöffnet, ein paar Anpassungen machen müssen, da teilweise neue Eigenschaften in Objekten waren und danach kompiliert.

Was soll ich sagen: Läuft jetzt auch mit FileExists

Wenn es nicht mir selbst passiert wäre, hätte ich das schwerlich geglaubt.
Der Umstieg auf Laz 2.0.10 mit Fpc 3.2.0 hat mir schon einige Probleme bereitet gehabt.
Ich werde jetzt erst mal abwarten auf ein neues Release und das dann besser testen, bevor ich es produktiv setze.

[Niesi]

So ähnlich ging's mir auch: Bei mir habe ich mit Laz 2.0.10 entdeckt, dass die Konsole nicht geöffnet wird ... ich habe ein Beispiel rausgesucht, da ich hier einer jungen Dame Pascal beibringe. Mit einer Installation von Lazarus 2.1 + Free-Pascal 3.2.1 funktioniert das Beispiel einwandfrei ...

Da ich unsicher bin, ob es an meiner Installation liegt, wollte ich sie mit fpcupdeluxe erneuern - es kamen viele Fehlermeldungen und nichts brauchbares. Viele Meldungen beschrieben nicht mögliche Downloads, also dachte ich, dass es daran liegt, dass ich in China bin - mein Sohn hat dieselbe Installation in Deutschland angestoßen. Es kam leider auch dasselbe raus ...
Nun habe ich es noch einmal in fpcupdeluxe und einer 2.1 + 3.2.1 versucht und: es läuft.

Und nun weiß ich auch nicht ...

[gladio]

kann es vielleicht sein,dass es an fpcupdeluxe (wasauch immer das ist) liegt?

[PascalDragon]

Ich werde jetzt erst mal abwarten auf ein neues Release und das dann besser testen, bevor ich es produktiv setze.

Es wäre auch sehr hilfreich, wenn die Leute mehr unsere RCs testen würden, dann könnten solche Fehler vielleicht gefunden werden, bevor wir ein Release freigeben.

[six1]

@PascalDragon
Ja, das ist vielleicht berechtigte Kritik...
Ich habe schon die RCs getestet, muss dazu aber anmerken, dass dies nicht immer so leicht ist, wie es sich anhört.
Da sind z.B. die DEVART SecureBridge Komponenten, welche ich benötige und auch BGRA Grafik, welche nicht immer auf den RCs laufen.
Bei den DEVART Komponenten habe ich die Sourcen und auch schon einige Anpassung vorgenommen um zu Testen, was jedoch auch nicht immer zielführend ist. DEVART kommt dann mit einem Versionsupgrade, welches nicht dem entsprechen muss, was ich da gefummelt habe; nur mal als Beispiel.
Dann sind da noch Dinge wie: Microsoft führt ein L-Attribut ein und unsere Share wird auf irgend eine neue Version upgedatet (worauf ich in keiner Weise Einfluss habe!) und schon geht FileExists nicht mehr.
Manchmal ist es eben anders, als es scheint...
In Laz 2.0.10 und fpc 3.2 scheint ein größeres Update gewesen zu sein, mit vielen tiefgreifenden Änderungen; vielleicht dauert es eben seine Zeit, bis wieder alles rund läuft. Es sind ja auch z.T. sehr spezielle Dinge, welche nicht sofort offensichtlich passierten, welche ich erfahren habe.

Dies ist auch in keiner Weise irgend eine Kritik! Ich bin froh, dass es laz und fpc gibt.
Jede! neue Version von Delphi war erst mit dem ersten Update richtig lauffähig... insofern schlägt sich das Laz Entwicklerteam hervorragend!

[six1]

Ok, ich habe jetzt mal tiefer gesucht...
Mit fpc 3.0.4 funktioniert alles 1a.
Fpc Versionen darüber habe für fileExists einen zweiten Parameter: FollowLink : Boolean = true

Da es sich bei in meinem speziellen Fall um einen Zugriff auf eine SAN handelt, welche noch irgend welche Verzeichnisse über Verknüpfungen einhängt, ist "FollowLink=true" fatal.
Stelle ich FollowLink auf false, wird der Pfad erkannt.

Soweit so gut könnte man meinen... ist es aber nicht.
Nachfolgend nach der Prüfung auf Existenz des Files, lade ich die Datei (.lrf) in einen Report und da kracht es wieder.

frReport.LoadFromFile( Dateiname);
Ab da wird in LR_CLASS Zeile 10560 TfrReport.Loadfromfile(const Fname : string) aufgerufen
danach LoadFromXMLFile in Zeile 10578 in LR_CLASS
weiter auf CheckFileExsists in Zeile 11827 in LR_CLASS

Genau diese CheckFileExsists Funktion macht aber nun Probleme, da sie den Parameter FollowLink nicht kennt und einen Aufruf auf FileExistsUTF8 ausführt.
Die Funktion FileExistsUTF8 ist in winlazfileutils und ruft ihrerseits wieder SysUtils.Fileexists auf, welche den FollowLink Parameter nicht bekommt.

Lösung für mich im Moment:
1) Fileexists für Zugriff auf Shares sicherheitshalber mit zweitem Parameter "false", zumindest es sich nicht um Links sondern echte Dateien handelt
2) ich fixe winlazfileutils . FileExistsUTF8 den Aufruf von sysutils.Fileexists erst mal mit zweitem Parameter "false" fest codiert

[PascalDragon]

Da es sich bei in meinem speziellen Fall um einen Zugriff auf eine SAN handelt, welche noch irgend welche Verzeichnisse über Verknüpfungen einhängt, ist "FollowLink=true" fatal.
Stelle ich FollowLink auf false, wird der Pfad erkannt.

Bedenke, dass in älteren Versionen von FPC das Verhalten von FileExists so ist als ob der FollowLink-Parameter fix True ist (daher auch der Default-Wert für den neuen Parameter). Du brauchst FollowLink = False eigentlich nur, wenn du mit der Datei, die den symbolischen Link repräsentiert, selbst arbeiten möchtest, was beim Öffnen von Dateiinhalten eben nicht der Fall ist. Berechtigungen sollten das bereitstellende Betriebssystem sowie der Administrator korrekt behandeln.

Genau diese CheckFileExsists Funktion macht aber nun Probleme, da sie den Parameter FollowLink nicht kennt und einen Aufruf auf FileExistsUTF8 ausführt.
Die Funktion FileExistsUTF8 ist in winlazfileutils und ruft ihrerseits wieder SysUtils.Fileexists auf, welche den FollowLink Parameter nicht bekommt.

Du solltest wohl auch einen Bugreport für LazReport und Lazarus einstellen, damit deren CheckFileExists und FileExistsUTF8 erweitert wird.

[six1]

@PascalDragon
Also beim Zugriff auf die SAN (DFS mit zig NAS) funktioniert FileExists exakt anders herum, wie Du beschreibst...
mit "FollowLink=true" bekomme ich false zurück, mit "FollowLink=false" bekomme ich true zurück, also Datei existiert...

Vor allem war ich mit meinem Lösungsansatz vorhin voreilig... es rennt immer noch nicht, da FileExsists an zig Ecken drin ist..

Komisch, dass ich der einzige bin, der damit Probleme hat. Es muss an der speziellen Umgebung liegen, in welcher ich arbeite.
Wie geschrieben: Mit Laz 2.0.8 fpc 3.0.4 geht es ja einwandfrei.
Das sind dann auch die Ecken und Kanten die ich beschrieb, so eine Entwicklungsumgebung mit allen Komponenten zu testen... nicht so einfach
Sicher sind auch noch viele anderen Komponenten davon betroffen... das kann ich gar nicht alles durchtesten. Zwischendrin muss ich irgendwie produktiv sein

Mir bleibt im Moment wirklich nur, die Laz 2.0.8 zu verwenden...

[PascalDragon]

@PascalDragon
Also beim Zugriff auf die SAN (DFS mit zig NAS) funktioniert FileExists exakt anders herum, wie Du beschreibst...
mit "FollowLink=true" bekomme ich false zurück, mit "FollowLink=false" bekomme ich true zurück, also Datei existiert...

Hast du mit 3.2.0 getestet oder 3.2.1/3.3.1?

3.2.0 ist hier ja fehlerhaft und wenn der Link auf dem Netzwerk Storage das "falsche" Format hat (was eben den Bug auslöst), dann gibt es tatsächlich False zurück bei FollowLink = True. Bei FollowLink = False wird einfach nur die Existenz des symbolischen Links überprüft.

Würdest du also bitte mal mit 3.2.1 oder 3.3.1 testen, falls du das noch nicht getan hast, damit wir wissen, ob es tatsächlich hieran liegt und nicht noch ein anderes Problem in FileExists schlummert?

[six1]

Dem komme ich gerne nach.
Ich hatte dafür ja extra mit fpcupdeluxe Laz 2.0.10 und fpc 3.2.1 erstellt; da war ich mir sicher. (ich hatte ja im englischen Teil gelesen, dass der Fehler in der 3.2.0 in 3.2.1 gefixt wurde!)
Eben schaue ich nochmal genau nach und: fpc 3.2.0 Peinlich, ich weiß...

Also erstelle ich jetzt mal schnell die richtige Version und teste mit einem Minimalbeispiel...

Gebe Bescheid, ob es dann in DFS/NAS klappt...

[six1]

@PascalDragon

Ok, muss mich erst mal entschuldigen.
Ich hatte tatsächlich die fpc release_3_2_0 installiert gehabt... warum auch immer; verklickt.

Mit der jetzt neu erstellten Version Laz 2.0.10 und fpc 3.2.1 (fix_3_2_0) funktioniert es!

Das andere Problem, dass der zweite Parameter in vielen Komponenten für FileExists nicht übergeben werden kann, ist eine andere Baustelle.
Inwiefern das nötig wäre, kann ich nicht beurteilen.

Danke für deine Unterstützung!

[PascalDragon]

Mit der jetzt neu erstellten Version Laz 2.0.10 und fpc 3.2.1 (fix_3_2_0) funktioniert es!

Puh... Das beruhigt mich, da wir in den Endvorbereitungen für 3.2.2 sind...

Das andere Problem, dass der zweite Parameter in vielen Komponenten für FileExists nicht übergeben werden kann, ist eine andere Baustelle.
Inwiefern das nötig wäre, kann ich nicht beurteilen.

Am Besten Bugs für jede solche Stelle melden, damit es sich jemand ansieht, der mehr in der Materie drin ist und diese Entscheidung treffen kann.

[BeniBela]

Es wäre auch sehr hilfreich, wenn die Leute mehr unsere RCs testen würden, dann könnten solche Fehler vielleicht gefunden werden, bevor wir ein Release freigeben.

Da wäre es auch hilfreich, einen Zeitplan zu haben, wann welche Version/RC veröffentlich wird. Sonst ist das Release plötzlich schon da, während man noch am testen ist. Vor allem weil es manchmal 2 und manchmal nur einen RC gibt

[PascalDragon]

Da wäre es auch hilfreich, einen Zeitplan zu haben, wann welche Version/RC veröffentlich wird. Sonst ist das Release plötzlich schon da, während man noch am testen ist. Vor allem weil es manchmal 2 und manchmal nur einen RC gibt

Es ist schwierig einen Plan für etwas zu machen für das es keinen Plan gibt.
Wenn aber auch niemand sagt, "Hey Leute, ich teste noch" und wir auch sonst keine Probleme in ein, zwei Wochen oder so hören, dann gehen wir davon aus, dass es keine Problem gibt.

[six1]

@ PascalDragon

Meine persönlichen Probleme mit neuen LCL/FPC hatte ich bereits oben beschrieben.
Was ich jetzt dazu beitragen kann ist, dass nach Installation über fpcupdeluxe die Version 2.0.11 / 3.2.1 einwandfrei läuft.
Ich habe meine "problematischen" Komponenten alle installiert bekommen und die arbeiten auch alle.
Auch DEVART SecureBridge in der Version 9.4.1 läuft damit einwandfrei.

Wenn also die Version LAZ 2.0.11 und FPC 3.2.1 die Kandidaten für das nächste Release wären, wäre es von meiner Seite aus OK.

Da ich in einer abgeschotteten, speziellen Umgebung arbeite, müsste ich also wissen, auf welche Konstellation es hinaus läuft, dann kompiliere ich mir diese Version zusammen und könnte vorab testen, ob "spezielle" Probleme auftauchen