![]() |
Dateien sind nicht da wo sie sein sollten...
Hi,
sorry für den Titel, aber mir fällt sonst nix ein. Ich habe hier ne Software, mit Delphi 10.4 gebaut, jahrelang im Einsatz, viele Kunden. bei einem (1) Kunden seit Jahresbeginn folgendes Phänomen: Aus der Anwendung raus wird ein Javaprogramm gestartet, mit eigener, mitgelieferter OpenJRE umgebung. In dem Prozess werden in einem definierten (von mir vorgegebenen) Verzeichnis eine handvoll Dateien erzeugt. Der Prozess beendet sich dann wieder, die Delphi-Anwendung soll dann aus dem Verzeichnis eine PDF öffnen. So weit so gut. Nun stellt sich die Situation beim Kunden so dar, dass das Java.exe läuft, abgeschlossen wird, die Steuerung wieder zurück zum Delphiprogramm geht, wird mit "if Fileexists()" versucht die PDF zu finden. Nur ist die bei dem Kunden dann nicht da und er bekommt ne hübsche Fehlermeldung. Wenn ich den Start des Javaprogramms etwas umbiege, dass eine GUI startet anstelle einer Konsolenanwendung, dann kann ich problemlos aus der GUI anwendung raus, die Dateien erzeugen und die erzeugte PDF öffnen. Die geht konkret im Internetexplorer auf (einen andneren PDF Viewer habe ich auf der Kiste nicht). Wenn ich jetzt (das PDF ist offen!) in das Verzeichnis gehe (mit dem Windows Explorer), dann zeigt der Windows-Explorer mir nackte leere an, d.h. keine Dateien. Dann kann ich in Folge coole Dinge tun: im Internetexplorer die Datei (PDF) die angezeigt wird, in der TItelleiste den Dateinamen entfernen, dann wird mir der Verzeichnisinhalt angezeigt: und sie he da: Alle erwarteten Dateien sind da - aber halt nicht im Explorer (auch nicht in der Powershell, auch nicht im cmd). Wenn ich einen weiteren Internetexplorer starte und die selbe Datei versuche aufzurufen, bzw. mir das Verzeichnis anzeigen lasse, dann ist da wieder absolute leere. Cool auch: Ich kann im Explorer eine Datei oder ein Verzeichnis anlegen und wenn ich den Browser mit F5 aktualisieren lasse, dann zeigt der mir das Verzeichnis neben den von dem Javaprogramm erzeugten Dateien auch im IE an - sowohl in dem IE mit den vielen Dateien die ich suche als auch im zeitgleich offenen IE der nix anzeigt. Mit meinen Versuchen kann ich also ausschließen, dass ich in einem anderen Verzeichnis bin. Schon bei den letzten beiden Kontakten zu dem Thema konnte ich ausschließen bzw. habe nichts dergleichen gefunden, dass hier die Verzeichnisvirtualisierung zuschlägt (wir befinden uns unterhalb von Programdata). Interessant auch: bisher war das Problem nach ein paar Tagen von alleine wieder weg (bisher 2x, jetzt das dritte mal), d.h. Rechner neustarten und co macht keinen Unterschied. Hat jemand irgend eine Idee was das für eine tolle Funktion da rein spielt? |
AW: Dateien sind nicht da wo sie sein sollten...
Win11 vermutlich?
Möglicherweise ein Virenscanner. Nach einem Signaturudate geht es wieder. Wenn Du im Explorer die Anzeigeoptionen änderst, Hiddenfiles und Systemfiles anzeigen, Versteckte Systemordner anzeigen. Komprimierte Ordner andersfarbig, wird es da interessanter? System Error Log? Mal ProcessMonitor mitlaufen lassen? |
AW: Dateien sind nicht da wo sie sein sollten...
Das klingt aber trotzdem sehr danach, als würde Windows die Schreibzugriffe in einen virtuellen Ordner umleiten, weil im richtigen Ordner nicht geschrieben werden darf.
Hast Du mal unter "C:\Users\[Username]\AppData\Local\VirtualStore" geschaut, ob dort etwas angelegt wird? |
AW: Dateien sind nicht da wo sie sein sollten...
Wer kommt auf die irrsinnige Idee, den IE noch benutzen zu wollen?
In welches Verzeichnis lasst ihr diese Dateien schreiben? Jetzt sagt nicht, dass ihr mit uralten schrottigen Programmen in Verzeichnisse schreiben/lesen wollt, die seit 25 Jahren "eigentlich" schreibgeschützt sind? Eure Dateien findet ihr nicht zufällig dort drin?
Delphi-Quellcode:
(einfach diesen Pfad so in die Adresszeile des Explorers kopieren und [Enter])
C:\Users\%username%\AppData\Local\VirtualStore
![]() |
AW: Dateien sind nicht da wo sie sein sollten...
Habe mal Deinen Text oben per Copy&Paste an drei KIs gegeben. Sie liefern alle drei eine Vielzahl von möglichen Ursachen und von Lösungsansätzen.
Die Ergebnisse sind zu umfangreich, um sie hier reinzukopieren. Eventuell versuchst Du ja dort mal dein Glück: ![]() ![]() ![]() Alle halten Antivirensoftware, Explorercache und Virtualisierung für verdächtig. Rechteprobleme werden auch nicht ausgeschlossen. Scheint insgesamt ein sehr ungewöhnliches Verhalten zu sein, auf dass Du da beim Kunden gestoßen bist. Die Vorschläge von gubbe und himitsu sind bei allen dreien mit auf der "Prüfliste". |
AW: Dateien sind nicht da wo sie sein sollten...
speziell der Aspekt, dass es mit der GUI läuft, aber via Console nicht .... PS, das Problem hat auch Delphi.
![]() |
AW: Dateien sind nicht da wo sie sein sollten...
sorry, leute, hier noch ein paar INformationen:
Die Dateien werden unter c:\programdata geschrieben, also nix alte gammelsoftware. Virtualstore geprüft: nix zu finden ja, ist Win11 und Korrektur: IE = Edge, sorry. Und versteckte Dateien und co: dann sollten die mit einem dir (cmd) oder ls (powershell) auftauchen bzw. durch ein FileExists gefunden werden |
AW: Dateien sind nicht da wo sie sein sollten...
Zitat:
Die Frage ist wo die Dateien landen. Vermutlich klappt das auch mit der Console, wenn das geht werde ich morgen versuchen nach dem Aufruf der KOnsole, die PDF zu öffnen in der batch. innerhalb des Prozesses sind die Dateien sichtbar, außerhalb halt nicht. Wäre noch interessant, ob ich diese dann auch kopieren kann. |
AW: Dateien sind nicht da wo sie sein sollten...
Auch auf C:\ProgramData hat standarmäßig nicht jeder Schreibzugriff. (abgesehn Administratoren und Systemdiensten)
Relativer Pfad, anstatt Absolutem, für die Dateiausgabe? |
AW: Dateien sind nicht da wo sie sein sollten...
Zitat:
Wenn das Speichernde und das Lesende anders reagieren, kann es sein, dass der Andere nichts oder was Anderes sieht. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz