[gelöst] Datenverlust: fhem.cfg wird bei "Cannot load module" überschrieben

[betateilchen]

Man könnte sich überlegen, eine Kopie der fhem.cfg zu speichern,

das macht FHEM seit Mittwoch automatisch.

Code Auswählen Erweitern


15377 by rudolfkoenig, 17:59 Hide 6 Items
fhem.pl: save writes a copy into restoreDirs (Forum #78769)


[Thorsten Pferdekaemper]

das macht FHEM seit Mittwoch automatisch.

Code Auswählen Erweitern


15377 by rudolfkoenig, 17:59 Hide 6 Items
fhem.pl: save writes a copy into restoreDirs (Forum #78769)


Bist Du Dir sicher, dass das das ist, was ich gemeint habe? Es klingt für mich eher so, dass ein "save" den alten Stand sichert. Was ich aber gemeint habe ist ein Sichern des neuen Stands. Also z.B. immer wenn sich etwas "fhem.cfg-relevantes" getan hat, dann eine Datei schreiben, aber eben nicht nach fhem.cfg. Um zu viel Datenmüll zu vermeiden kann man das ja auf eine Sicherung pro Minute/10 Minuten plus eine beim shutdown (oder wie auch immer) beschränken.
Gruß,
   Thorsten

[betateilchen]

Bist Du Dir sicher, dass das das ist, was ich gemeint habe?

Vermutlich nicht, aber es ist besser als gar nix.

Also z.B. immer wenn sich etwas "fhem.cfg-relevantes" getan hat, dann eine Datei schreiben, aber eben nicht nach fhem.cfg.

...sondern in die configDB. Die ist genau dafür ausgelegt.

[rudolfkoenig]

Daraus lese ich, dass ein Modul nicht mehr prüfen muss, ob "global autosave" gesetzt ist, sondern soll bei strukturalen Änderungen 'AnalyzeCommand(undef, "save")' aufrufen.

Pruefen muss es nicht, aber save ausloesen _muss_ es auch nicht.

Diese Diskussion hatten wir schon vor zwei Jahren, damals ist das global autosave Attribut reingekommen.
Ich bin der Ansicht, dass FHEM Module kein autosave ausloesen sollten. Es gibt aber das Problem, dass manchmal Aenderungen in einem anderen System auch in FHEM Spuren hinterlassen, und wenn man die FHEM Konfiguration nicht speichert, dann hat man nach Neustart was Kaputtes. Ich meine in solchen Faellen ist ein save gerechtfertigt.

Die Idee von Thorsten ist interessant, allerdings ist es (noch?) nicht sehr anfaengerfreundlich: man hat zwei Optionen beim Start, und im Zweifel startet man mit dem falschen fhem.cfg.
Neuer Vorschlag: global autosave kann die Werte 0,1,2 aufnehmen. 0: nur Benutzergesteuert speichern, 1: wie jetzt, halbautomatisch, 2: zusaetzlich nach jeder Strukturaenderung, mit X Sekunden delay, damit das "batch"-setzen von 10 Attributen nicht 10 Speichervorgaenge ausloest. Die Voreinstellung bleibt bei 1.

[betateilchen]

Kann ich auch was von dem Zeugs haben, das Ihr raucht?

Wer, der nicht drei Jahre intensive FHEM Nutzung hinter sich hat, soll denn das noch verstehen und sinnvoll einsetzen? Es ist doch jetzt schon absehbar, dass in irgendwelchen Internet-Blogs dann die Empfehlung gegeben wird, auf ,,maximale Sicherung" umzustellen. Und was das dann wieder an Problemen und Fragen aufwirft, schlägt dann hier im Forum auf. Und wenn es ,,woanders" empfohlen wird, kriegst Du das hier nie wieder gradegezogen.

[betateilchen]

Ausserdem sollte es nicht Aufgabe der fhem.pl sein, jeden Schwachsinn denn irgendwelche Frickler "Entwickler" in ihren Modulen verbrochen haben, wieder ausbügeln zu wollen.

Da wäre ich lieber für eine bessere Qualitätssicherung von Modulen VOR dem Einchecken und der Veröffentlichung. Z.B. ein pre-commit-hook, der CommandSave() verbietet.

[dev0]

Neuer Vorschlag

Finde ich gut. Falls Option 1/2 beinhaltet, dass nach einem Fehler beim FHEM Start nicht mehr automatisch gespeichert wird, dann sollte mAn der Anwender darüber informiert werden.

[Thorsten Pferdekaemper]

Die Idee von Thorsten ist interessant, allerdings ist es (noch?) nicht sehr anfaengerfreundlich: man hat zwei Optionen beim Start, und im Zweifel startet man mit dem falschen fhem.cfg.
Neuer Vorschlag: global autosave kann die Werte 0,1,2 aufnehmen. 0: nur Benutzergesteuert speichern, 1: wie jetzt, halbautomatisch, 2: zusaetzlich nach jeder Strukturaenderung, mit X Sekunden delay, damit das "batch"-setzen von 10 Attributen nicht 10 Speichervorgaenge ausloest. Die Voreinstellung bleibt bei 1.

Naja, das ist aber genau umgekehrt als das, was ich gemeint hatte. Ich meinte, dass man nie die fhem.cfg automatisch speichert, sondern Änderungen "vorsorglich" in eine andere Datei (oder eine Reihe anderer Dateien) speichert. Wenn man dann mal vergisst "save config" zu drücken, dann kann man sich den neusten Stand (manuell) von dort holen.

...sondern in die configDB. Die ist genau dafür ausgelegt.

Woher weiß die configDB dann welchen Stand der Konfiguration mein FHEM benutzen soll?

Gruß,
   Thorsten

[Timmy.m]

Habe die oben vorgeschlagenen Aenderungen eingebaut, getestet und eingecheckt.

Vielen Dank, gute Sache.. etwas finde ich nur unglücklich gelöst.

- Mache ich ein Update von FHEM wird ins "restoreDir" mit dem aktuellen Daten ein Backup angelegt. -> Soweit so gut.
- Speichere ich dann die Konfiguration nach ein paar Änderungen ab, landet diese im gleichen Backup Verzeichnis meines FHEM Backups.
In meinen Augen erhöht sich die Gefahr sich seine Backup Daten zu zerschießen. Ich würde es bevorzugen, wenn die Konfigurationsdaten in einen anderen Ordner im "restoreDir" gespeichert wird oder noch besser eine Anzahl von Backups dort bevorratet wird und man in FHEM einstellen kann, dass man die älteste nach z.B. 5 neuen Sicherungen löscht.

Grüße Tim