Frühzeitige Bestätigungsdialoge

Moderator: pandel

Antworten
dark alex
Beiträge: 326
Registriert: 11 Mär 2015, 10:09

Frühzeitige Bestätigungsdialoge

Beitrag von dark alex »

Ist dir eigentlich schon aufgefallen, dass dein Tool sehr häufig bereits bevor das Packen tatsächlich fertig ist Erfolg vermeldet?
Die Folge ist, dass dann die Buttons ausgegraut bleiben (Gott sei Dank) und erneutes Packen anfangs fehlschlägt (Vermutlich wegen Locks).
pandel
Beiträge: 830
Registriert: 25 Jan 2013, 16:47

Re: Frühzeitige Bestätigungsdialoge

Beitrag von pandel »

Nein, , dass das vorher passiert, ist mir noch nicht aufgefallen. Ich weiß nur, dass er Erfolg meldet, die Buttons aber ausgegraut bleiben, weil aus irgendeinem Grund die Datei noch nicht auffindbar ist, obwohl sie im Dateisystem schon da ist. Da krieg das K**zen drüber, weil ich das nicht in den Griff bekomme :evil: !
dark alex
Beiträge: 326
Registriert: 11 Mär 2015, 10:09

Re: Frühzeitige Bestätigungsdialoge

Beitrag von dark alex »

Wartest du auf den Exitcode?
Versuch das mal ein sync auszuführen bevor du checkst... Nur so ein Gedanke...
dark alex
Beiträge: 326
Registriert: 11 Mär 2015, 10:09

Re: Frühzeitige Bestätigungsdialoge

Beitrag von dark alex »

Gibt's dazu News?
pandel
Beiträge: 830
Registriert: 25 Jan 2013, 16:47

Re: Frühzeitige Bestätigungsdialoge

Beitrag von pandel »

Nein. Ich warte weder auf einen Exicode, noch auf sonstwas, ein Sync hilft nicht wie gewünscht, eine komplette Änderung der Programmierung durch Verwendung andere Bibliotheken etc. hat bis dato auch nichts gebracht. Ich weiß es echt nicht und es nervt :evil:
dark alex
Beiträge: 326
Registriert: 11 Mär 2015, 10:09

Re: Frühzeitige Bestätigungsdialoge

Beitrag von dark alex »

:mrgreen: :roll:

Ich kenn das irgendwo her...
pandel
Beiträge: 830
Registriert: 25 Jan 2013, 16:47

Re: Frühzeitige Bestätigungsdialoge

Beitrag von pandel »

So... ich denke, ich weiß jetzt woran es liegt ;-)

Es liegt an der Art wie Windows auf Basis des SMB2 Protokoll Datei- und Ordnerdaten zwischenspeichert - dazu gibt es Lifetimewerte (näheres hier: https://technet.microsoft.com/de-de/lib ... s.10).aspx). Da ein Paket direkt auf dem Server in dem jeweiligen Ordner angelegt wird, ich die Vorhandenseinsprüfung aber aus Sicht des Clients durchführe, kann es sein, dass Windows nach Fertigstellung des Pakets seinen eigenen Cache noch nicht verworfen hat. Damit ist das Paket aus Clientsicht noch nicht sichtbar und es kommt zu dem besagten Fehlverhalten.

Ich habe in der 8.1.7 jetzt versucht, dass mit einem Trick auszuhebeln:
Wenn jetzt ein Paket gebaut wird, wird vorher eine temporäre Datei im Zielordner über den oPB (also vom Client aus gesehen) angelegt, dann läuft der eigentlich Build-Prozess am Server, dann wird die temporäre Datei geflusht und geschlossen, was sie automatisch entfernt. Somit ist der Client gewzungen, auf dem Share rumzumachen, was ihn hoffentlich zuverlässig dazu bringt, den Cache zu erneuern. Bis jetzt sieht es aber so aus.

Aus der Praxis:
Am schlimmsten war das bei einem Kollegen, der regelmäßig ein Paket komplett via Kommandozeile baut, installiert und auf setup setzt. Da hat das ganze oft einfach nur die Bauphase geschafft, aber danach war dann Schluß. Mit dem Umbau in der 8.1.7 scheint es derzeit aber ganz brauchbar zu laufen, denn bis dato ist ihm das nicht wieder passiert.

Ich kann nur hoffen, dass das dauerhaft hilft. Wenn nicht, bleibt mir nichts anderes übrig, als nach dem Build eine Verzögerungs- bzw. Wartzeit einzurichten, um diesen ganzen Mist zu kompensieren. Alternativ kann man die Cache Lifetime auch am Client in der Registrierung ändern, aber da kann ich naturgemäß ja nicht einfach dran herumfummeln :mrgreen: !
Antworten