Dateieigenschaften im Netzwerk und Delphi EXE

[Jasocul]

Die Probleme kenne ich. Das liegt mit großer Wahrscheinlichkeit am Virenscanner.
Für unsere lokalen Rechner sind bestimmte Verzeichnisse für den Scan ausgenommen. Diese Verzeichnisliste war zwischendurch mal defekt. Dadurch wurde das Kompilieren furchtbar langsam.
Kopiere ich eine EXE innerhalb dieser Verzeichnisse ist das sehr schnell. Kopiere ich lokal in ein zu prüfendes Verzeichnis, ist es langsamer aber immer noch akzeptel. Kopiere ich von lokal über VPN ins Netzwerk geht es auch noch, wobei die Geschwindigkeit der Verbindung eine Rolle spielt. Was sonst 3-4 Sekunden dauert, kann dann schonmal 20-30 Sekunden dauern.
Bis dahin alles nachvollziehbar.

Eigenschaften und Kontextmenü:
Lokal verhält es sich, wie man es erwarten würde.
Netzwerk über VPN ist die Hölle. Selbst ein Strg-C kann vereinzelt zum scheinbaren Stillstand führen.

Vermutlich muss der Scanner bei jedem relevanten Vorgang die gesamte Datei scannen und diese dafür über die Leitung ziehen. Je nachdem was im Kontextmenü relevant für eine Prüfung ist, wird das möglicherweise mehrfach gemacht. Mit den Eigenschaften der Datei dürfte sich das ähnlich verhalten.

Abhilfe wird eine Signatur nur schaffen, wenn diese vom Virenscanner berücksichtigt wird. Ob dafür aber wieder die ganze Datei einmal gelesen werden muss, weiß ich nicht.

Zur Prüfung meiner Vermutung kann man entweder den Scanner ausschalten oder den Ordner des Netzwerks probeweise in die Liste der Ausnahmen aufnehmen. Leider steht mir diese Möglichkeit nicht offen, ohne einen Admin zu überreden unsere Richtlinien zu ignorieren . Zum Glück habe ich nur sehr selten den Bedarf sowas zu machen.

[jaenicke]

Hilfreich ist dabei auch ein Upgrade auf Windows 11. Durch die Auslagerung in ein Untermenü geht das Kontextmenü dort sehr viel schneller auf. Allerdings verhunzen viele Anbieter das gerade wieder, indem sie sich wieder in die obere Ebene setzen. Solche Sondermüll-Apps fliegen aber bei mir hochkant vom System.

[himitsu]

Die EXE liegt aber nicht im Rootverzeichnis des Share?
Dort hat Windows ein paar "optimierte" Eigenarten, ganz besonders beim Starten von EXEn mit vielen DLL/BPL.

[haentschman]

Danke...

Ich gehe jetzt erst Mal dem Virenscanner und dem Zertifikat nach.

Zitat:

Die EXE liegt aber nicht im Rootverzeichnis des Share?

...nein.

[himitsu]

Schau auch mal mit einem Log-Tool (ProcessMonitor usw.)

Bezüglich dem RootVerzeichnis, denn Windows greift bei Shares immer auf das übergeordnete Verzeichnis der EXE und darin ein anderes Unterverzeichnis zu, um dort irgendwelche Daten zu suchen.
..\ sollte eigentlich nicht weiter zurück gehen, aber beim \\computer\share, wenn man da blind einfach die VerzeichnisManipulationsFunktionen für lokale Laufwerke ala C:\ nutzt, dann wird dort einmal auf den Computer selbst und dann auf ein nichtexistierenden Share zugegriffen, was bei einem standardmäßig 10-sekündigen Timeout, ab dem 10. bis 20. Zugriff, für gefühlt 300 EXE/DLL/BPL (DevExpress und Dergleichen, mit RuntimePackages) sehr sehr sehr lange für das Starten bedeutet, vor allem da unser SplashScreen in der EXE liegt und davor erst ALLE DLL/BPL der Imports geladen werden.