FireBirdLib

[ibbi]

sind meine Spezialität.

[Sigittarius-E]

Danke Alex

HDD_TruncateFile: Damit lässt sich eine Datei kürzen, z.B. um den Müll am Ende einer Log-Datei zu entfernen.

klingt sehr interessant für mich

[Happy]

Besteht Hoffnung, diesen Bug zu umgehen, dass TAPs die Vorspultaste nicht blockieren können.

Gruß,
Happy

[Happy]

[quote=""Happy""]Besteht Hoffnung, diesen Bug zu umgehen, dass TAPs die Vorspultaste nicht blockieren können.
[/quote]
Habe noch ein wenig probiert. Die Rückspultaste ist auch betroffen.
Da Problem besteht aber nur im "Normalzustand". Daher sind TAPs mit OSD, die TAP_ExitNormal aufgerufen haben, nicht betroffen.

Gruß,
Happy

[ibbi]

Wie ist denn die Meinung zu dieser Idee, vor dem Shutdown einen TAPCOM-Broadcast zu versenden?

[Elle4u]

[quote=""ibbi""]Wie ist denn die Meinung zu dieser Idee, vor dem Shutdown einen TAPCOM-Broadcast zu versenden?[/quote]

Ich finde es gut (auch wenn ich noch nicht weiß, wie ich Filer beibringe darauf zu lauschen ).
Allerdings müsste man sich auf eine Zeit einigen, welche gewartet wird. Oder meldet das dann jeder Client zurück?

[ibbi]

[quote=""Elle4u""]Allerdings müsste man sich auf eine Zeit einigen, welche gewartet wird. Oder meldet das dann jeder Client zurück?[/quote]

Du meinst Server.

Bei einem Broadcast gibt es leider keine Rückmeldemöglichkeit für jeden einzelnen, da ja alle mit demselben Channel arbeiten. Der Client (in unserem Fall die Shutdown-Funktion bzw. dasjenige TAP, welches diese Funktion aufgerufen hat), müsste also eine Weile warten, um sicherzugehen, dass alle ihre Arbeit abgeschlossen haben.

[Elle4u]

[quote=""ibbi""]Du meinst Server.[/quote]

erwischt

[quote=""ibbi""]...müsste also eine Weile warten, um sicherzugehen, dass alle ihre Arbeit abgeschlossen haben.[/quote]

OK.

[asrael]

Hallo,

habe gerade Probleme mit der Funktion Shutdown(TaskPower).

Führe ich die relativ bald nach dem Topf-Start aus, so beendet sich der Topf. Starte ich den Filer2 im Batch-Mode und führe nachdem sich Filer beendet hat, Shutdown(TaskPower) aus, so beendet sich der Topf nicht. Allerdings liefert der Funktionsaufruf TRUE zurück, so dass eigentlich der CallFirmware in Shutdown abgesetzt worden sein müsste.

Gibt es einen plausiblen Grund für dieses Verhalten? Eine Aufnahme lief zu dem Zeitpunkt nicht, der Topf war von Hand gestartet worden. Verhalten dreimal reproduzierbar.

Mit freundlichen Grüßen

asrael

[FireBird]

[quote=""asrael""]Gibt es einen plausiblen Grund für dieses Verhalten?[/quote]
Da gibt es ein Problem mit der Jan-Firmware. Genaueres weiss ich aber noch nicht.

[asrael]

[quote=""FireBird""]Da gibt es ein Problem mit der Jan-Firmware. Genaueres weiss ich aber noch nicht.[/quote]

Dankeschön. Hängt es denn mit der Topf-Laufzeit bis zum Shutdown-Versuch zusammen oder weißt Du gar nichts genaueres?

Mit freundlichen Grüßen

asrael

[FireBird]

Leider noch gar nichts. Das Problem ist, dass der FBLib-Anteil am Shutdown sehr gering ist. Unter Umständen muss ich vom Event auf einen Call umsteigen.

[asrael]

[quote=""FireBird""]Leider noch gar nichts. Das Problem ist, dass der FBLib-Anteil am Shutdown sehr gering ist. Unter Umständen muss ich vom Event auf einen Call umsteigen.[/quote]

So, ich habe mal gerade einen kleinen Test mit BootMenu gemacht, ich denke, die Befehle sind auch ohne BootMenu-Doku selbsterklärend.

Code: Alles auswählen

start System/TAPCommander
start /batch System/filer
; im Batch starten
echo Topfield shuts down now
shutdown

Leider kein shutdown!

Code: Alles auswählen

start System/TAPCommander
sleep 480
; 8 Minuten warten
echo Topfield shuts down now
shutdown

Shutdown erfolgt!

Code: Alles auswählen

start System/TAPCommander
start /batch System/batchtest
; eigenes Test-TAP
echo Topfield shuts down now
shutdown

Shutdown erfolgt!

Es liegt also nicht an der Zeit, die der Topf schon an ist (der Filer-Batch dauert bei mir etwa 8 Minuten). Es liegt auch nicht daran, dass überhaupt TAPs gestartet werden (der TAP commander wird ja immer gestartet). Es liegt auch nicht am Batch-Start (eigenes Test-TAP verursacht kein Problem). Irgendwas passiert also im Filer-Batch-Modus, das den Topf hinreichend durcheinander bringt, um den shutdown zu verhindern.

Vielleicht hilft das ja beim Einkreisen des Problems.

Mit freundlichen Grüßen

asrael

[FireBird]

Danke für's Testen. Nachdem sich aber eindeutig an der Firmware was geändert haben muss, bin ich mir nicht sicher, ob ich die Art der Abschaltung nicht einfach ändere und hoffe, dass es klappt. Steht auf der ToDo, wird aber noch ein wenig dauern.

[Sigittarius-E]

Was genau macht HDD_TruncateFile?

Den Müll ( Differenz des geschriebenen bis zum nächsten 512er Block?) ersetzen oder kann damit wirklich abschneiden und das File nur so groß erstellen wie Bytes geschrieben werden?

Ein HDD_TouchFile danach kann vermutlich auch nicht schaden

[FireBird]

[quote=""Sigittarius-E""]Was genau macht HDD_TruncateFile?

Den Müll ( Differenz des geschriebenen bis zum nächsten 512er Block?) abschneiden und das File nur so groß erstellen wie Bytes geschrieben werden?[/quote]
Genau.

Ein HDD_TouchFile danach kann vermutlich auch nicht schaden

Sehe ich auch so.

[Sigittarius-E]

Danke.

Dann erspar ich mir eine Meldung in SCE auszugeben wenn auf 512er erweitert wird.

AFAIK hat ibbi ja festgestellt, daß mein Trick eine am PC erstellte und am Topf in gleicher Länge gespeicherte Datei nur dann nicht auf 512er Blöcke erweitert wird, wenn die Datei unter 512 Byte lag. Darüber werden trotzdem 512er erstellt.

[Sigittarius-E]

erste Tests mit HDD_TruncateFile liefen - wie sollte es anders sein - einwandfrei.

Jetzt kommt die eigentliche Frage: Könnte es TAPs geben, die eine 512er INI Datei beim Auslesen erwarten?

[FireBird]

Na ich hoffe nicht. Das macht bei einer Textdatei einfach keinen Sinn.

[Sigittarius-E]

[quote=""FireBird""]Na ich hoffe nicht. Das macht bei einer Textdatei einfach keinen Sinn.[/quote]

ok.

P.S.: ich hab durch den Einsatz von Truncate einiges im Source löschen können. .... und es funktioniert noch immer