Dateieigenschaften im Netzwerk und Delphi EXE

[haentschman]

Hallöle...

Ich hoffe ich kann das erklären.
Ich habe unseren Netzwerkfuzzi "rund" gemacht wegen angeblicher Performance Probleme...die wahrscheinlich keine sind.

Todo:
Eigenschaften einer EXE anzeigen über Speedcommander(oä.)

Problem:
1. Rechte Maustaste auf Datei
2. Kontextmenü geht auf...nach 2:30 Minuten!
3. Klick auf Eigenschaften...Fenster Eigenschaften nach Gesamtzeit 5:30!

Analyse:
1. Das betrifft nur eine Delphi EXE, nämlich die von meinem Projekt.
2. Bei einer größeren Datei, nicht Delphi EXE, am gleichen Ort werden die Eigenschaften sofort geöffnet.
3. Das ist sowohl im lokalen Netz in der Firma als auch über VPN Schei... Lokal sofort.

Frage:
Kennt das einer von Euch? Sind es Einstellungen im Projekt, die das verursachen?

Danke...

[LoZe]

wir hatten ein ähnliches Problem.
Nachdem wir mit dem Signieren unserer Exe-Dateien begonnen hatten, war es weg.

Ich würde versuchen, den Virenscanner auszuschalten und zu sehen, ob es dann besser ist.

[haentschman]

Die Datei ist signiert...aber mit einem "Self Certificate" Ich sollte das mal prüfen, ob unser eigenes Zertifikat auf diesem Server vorhanden und aktiv ist. Das mache ich aber nur mit dem Netztwerkfuzzi. Vieleicht kann man das in der Domain verteilen...

Danke...

[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.

[dummzeuch]

Zitat von haentschman:

Hallöle...

Ich hoffe ich kann das erklären.
Ich habe unseren Netzwerkfuzzi "rund" gemacht wegen angeblicher Performance Probleme...die wahrscheinlich keine sind.

Todo:
Eigenschaften einer EXE anzeigen über Speedcommander(oä.)

Problem:
1. Rechte Maustaste auf Datei
2. Kontextmenü geht auf...nach 2:30 Minuten!
3. Klick auf Eigenschaften...Fenster Eigenschaften nach Gesamtzeit 5:30!

Analyse:
1. Das betrifft nur eine Delphi EXE, nämlich die von meinem Projekt.
2. Bei einer größeren Datei, nicht Delphi EXE, am gleichen Ort werden die Eigenschaften sofort geöffnet.
3. Das ist sowohl im lokalen Netz in der Firma als auch über VPN Schei... Lokal sofort.

Frage:
Kennt das einer von Euch? Sind es Einstellungen im Projekt, die das verursachen?

Danke...

Das Problem kenne ich auch. Meine Vermutung ist, dass es durch das PE-Flag IMAGE_FILE_NET_RUN_FROM_SWAP hervorgerufen wird, ggf. im Zusammenhang mit zusätzlichen angehängten Daten (MO-Dateien zur Übersetztung + Debug-Info von jcldebug) und einem Virenscanner.
Aber so richtig beweisen kann ich das nicht.

[himitsu]

Beim IMAGE_FILE_NET_RUN_FROM_SWAP und IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP finde ich die Implementation seitens Microsoft eh mehr als fehlerhaft.
Die Flags von der EXE sollten sich auf alle DLL/BPL auswirken, wenn es dort aktiviert ist.
Es ist ja nicht grade förderlich, dass man im Grunde alle Fremd-DLLs bearbeiten und da im Header das Bit setzen muß, was sich erschwert, wenn die auch noch signiert sind.

Die sorgen aber auch nur, dass es eine Kopie im SWAP gibt, aber mehr muß deswegen aber dennoch nicht vom Share geladen werden.
* der Virenscanner lädt einmal alles
* dann wird Vieles zwar erstmal nur in den RAM gemappt, aber durch die Reallocationen (verschärft durch ASLR) wird dennoch fast alles sofort geladen (abgesehn von übergroßen Ressourcen)