Update - Befehl geändert?

[Elektrolurch]

Hallo,

seit einigen Tagen meldet mir "update check" das eine Reihe von Dateien in

www/images/*/...

aktualisiert werden würden.

Es handelt sich dabei um eine Reihe  von svg-Icon-Dateien, die ich ca. vor einem Jahr mit dem Editor geändert habe.
Das Änderungsdatum liegt also definitiv vor dem Zeitpunkt, seit dem "update check" behauptet, dass diese Dateien aktualisiert werden müssten.

Fragen:
1. Wie wird ermittelt, dass Dateien zu aktualisieren sind?
2. Ich habe schon versucht mit "touch" das Änderungsdatum auf heute zu setzen, fhem würde aber weiterhin diese Dateien aktualisieren und mir so überschreiben. Wie kann ich das verhindern? Jedesmal den alten Stand zurückschreiben, ist etwas lästig.

Gruß

Elektrolurch

[rudolfkoenig]

Bis vor kurzem hat update nur die lokale controls_fhem.txt Datei mit der von fhem.de verglichen, und die Unterschiede anhand dieses Vergleichs berechnet.

Neuerdings wird auch die Groesse der lokalen Datei im Filesystem geprueft, da es immer wieder Probleme gab, die nur mit einem "update force" loesbar waren.

Wenn jemand fuer bestimmte Dateien kein update wuenscht, der muss diese in exclude_from_update eintragen (attr global).

[Elektrolurch]

Danke, gute Erklärung und das erklärt auch mein Problemchen und es gibt auch eine Lösung.
Danke noch Mal.
Elektrolurch

[betateilchen]

Im Zusammenhang mit 98_update.pm schlage ich folgenden Patch vor, damit man während eines Updates die Chance hat, ausgeschlossene Dateien zu erkennen. Manchmal sucht man lange nach einer Ursache, warum ein File nicht per update aktualisiert wird, bis man irgendwann darauf kommt, dass die Datei in exclude_from_update enthalten ist.

Eine übersprungene Datei wird durch diesen Patch mit "IGN <fileName>" protokolliert.

Code Auswählen Erweitern

Index: FHEM/98_update.pm
===================================================================
--- FHEM/98_update.pm   (revision 8551)
+++ FHEM/98_update.pm   (working copy)
@@ -191,6 +191,7 @@
       $isExcl = 1 if($fName =~ m/$ex/);
     }
     if($isExcl) {
+      uLog 1, "IGN $fName";
       uLog 4, "update: skipping $fName, matches exclude_from_update";
       next;

     }


[rudolfkoenig]

Warum nicht einfach loglevel von 4 auf 1 aendern?

[betateilchen]

Weil mir die Ausgabe im Eventmonitor völlig ausreichen würde.

[ext23]

Nabend,

aha gut zu wissen und ich habe mich schon gewundert wieso genau die Module die ich per Hand anpassen muss jeden Tag aufs Neue im Update gelistet sind. Finde ich persönlich keine so glückliche Änderung. Selbst wenn die die entsprechenden Module "ausschließe" bekomme ich ja nicht mehr mit wenn wirklich ein Update dabei ist. Aber gut der Patch unten ist ja schon mal gut, aber dann muss ich das Modul auch gleich ausschließen was

Gruß
Daniel

[betateilchen]

Tja, ich finde die vorgenommene Änderung, auch die Dateigröße als Kriterium für eine Zwangsaktualisierung heranzuziehen, auch mehr als unglücklich 

[rudolfkoenig]

Weil mir die Ausgabe im Eventmonitor völlig ausreichen würde.

Die andere Zeile kommt mit loglevel 1 auch im Eventmonitor, und da es deutlich auffaelliger ist, als IGN statt UPD, habe ich das loglevel der alten Zeile angepasst. Da kann sich Daniel auch nicht mehr beschweren.

Tja, ich finde die vorgenommene Änderung, auch die Dateigröße als Kriterium für eine Zwangsaktualisierung heranzuziehen, auch mehr als unglücklich  (http://forum.fhem.de/Smileys/default/sad.gif)

Dazu haette ich gerne sachliche Argumente.
Ich will gegen dem "falls Du ein Problem mit update hast, verwende update force" Wahn vorgehen, und ich hatte bisher keine auswertbaren Hinweise, wann das Problem auftritt. Jeder, der etwas lokal modifiziert, sollte es in exclude_from_update eintragen, ich finde das eine einfache und klare Regel, auch aus der Support Sicht.

[betateilchen]

Ich will gegen dem "falls Du ein Problem mit update hast, verwende update force" Wahn vorgehen,

Das verstehe ich durchaus.

Dann bau doch nur das "update force" dahingehend um, dass auch die Dateigröße herangezogen wird und lass das reguläre update wie es früher war. Der Anteil der Leute, die tatsächlich Probleme beim Update haben und denen deshalb zu "update force" geraten wird, ist doch verschwindend gering, ich schätze unter 1%. Aber wegen dieser kleinen Gruppe hast Du nun für die Mehrheit der Anwender das update so umgebaut, dass auf Anwenderseite wieder Mehrarbeit (exclude_from_update nutzen) notwendig wird. Das finde ich schon reichlich "unfair" gegenüber den Anwendern, die gar kein update-Problem an sich haben.

[rudolfkoenig]

Bin mit deinem Vorschlag nicht einverstanden:
- die Loesung kann nicht sein, dass update force abgeschwaecht wird, und de fakto zu den aktuellen update ohne force umgebaut wird. Wie gesagt, ich will, dass update funktioniert, und update force normalerweise nicht verwendet wird.
- es wurde bisher nirgendwo versprochen, dass update lokale Dateien nicht neu schreibt, es sei denn, es ist in exclude_from_update eingetragen. Wer herumbastelt, sollte eh nicht fhem update sondern svn update verwenden.

[betateilchen]

Mach wie Du denkst. Anwenderfreundlich finde ich Deinen vorgenommenen Umbau jedenfalls nicht.

Würde "update" wirklich korrekt funktionieren, wäre übrigens weder ein "update force" noch Deine Hilfskrücke mit dem Größenvergleich überhaupt notwendig. Aber das Ziel, "update" zu einer korrekten Funktion zu bringen, wirst Du auch mit dem Größenvergleich nicht wirklich erreichen. Wieviele Krücken, die den Anwendern das Leben schwermachen, willst Du dann noch einbauen?

Die meisten Problem beim Update treten doch aufgrund der http Kommunikation auf und nicht, weil das update-Modul nicht funktionieren würde.

Kompromißvorschlag: Mach den Größenvergleich als Parameter für ein update bitte abschaltbar.

[Tom_S]

Ich finde die jetzige Lösung auch nicht so gut. Da ich auch ein paar Kleinigkeiten geändert habe, werden meine Änderungen jetzt mit jedem Update überschrieben. Es handelt sich ja nicht wirklich um ein Update, sondern um ein wiederherstellen des Originalzustand.
Mit exclude_from_update bekomme ich allerdings auch nicht mehr mit, wenn es wirklich ein Update gab.

Kompromißvorschlag: Mach den Größenvergleich als Parameter für ein update bitte abschaltbar.

wenn es nicht zu aufwändig ist, wären ich damit auch zufrieden.

oder noch einen Schalter "update all"

LG

[Elektrolurch]

Was spricht dagegen, statt der Größe das Änderungsdatum zu verwenden?
Alles was in der fhem-Installation neuer ist, wird nicht überschrieben.

[Benni]

Was spricht dagegen, statt der Größe das Änderungsdatum zu verwenden?
Alles was in der fhem-Installation neuer ist, wird nicht überschrieben.

Quasi als "touch and go" - Lösung 
(Sorry, aber den Kalauer konnte ich mir jetzt echt nicht verkneifen.)

Ansonsten finde ich Rudis Argumentation völlig in Ordnung: Wer lokal Änderungen an Dateien vornimmt, die normalerweise per Update ausgeliefert werden, sollte diese auch selbst schützen.

Gruß Benni.

[rudolfkoenig]

Ich habe noch keine Argumente bekommen, wieso die aktuelle Loesung nicht gangbar ist.

Falls jemand meint, eine neue Modulversion ist kaputt, der soll die Datei in exclude_from_update eintragen, er kriegt eine deutliche Meldung, dass die Datei vom update nicht ueberschrieben wird. Ich habe update gerade so angepasst, dass diese Meldung nur dann (einmal) kommt, falls es eine zentrale Aenderung der Datei erfolgte, bzw. beim single/force update.

Falls jemand ein Modul selbst weiterentwickelt/modifiziert, der moege das ueber SVN regeln, SVN wird die lokalen Aenderungen bei dem update beruecksichtigen.

[rudolfkoenig]

Da es mit configDB Probleme gab, habe ich die Pruefung der Dateigroesse in diesem Fall deaktiviert.
Und da ich schon bei Aendern war, gibt es auf Wunsch von betateilchen/Tom_S das Attribut updateNoFileCheck.

[betateilchen]

gibt es auf Wunsch von betateilchen/Tom_S das Attribut updateNoFileCheck.

Danke.

Für alle, die das Attribut suchen: Es ist in "global" zu verwenden.

[volschin]

Warum sind die update-Attribute, die unter global zu pflegen sind eigentlich nicht dort beschrieben? 

Konsequenz: Ich bin in global und versuche über "Device specific help" eine Erläuterung zu bekommen. Es findet sich aber nichts.

Nicht sehr benutzerfreundlich. 

[marvin78]

Sie sind im Modul update beschrieben. Zuerst würde ich wohl auch dort suchen, wie ich update verwenden und konfigurieren kann. Dass sie aber unter gobal nicht einmal verlinkt sind (wie andere Attribute), ist schon einigermaßen inkonsequent, das stimmt.

Ob es nun nicht benutzerfreundlich ist, lasse ich mal dahin gestellt. Ein wenig Suchen kann erlaubt sein und es ist nichts einfacher, als STRG+F zu drücken und nach "update" zu suchen. Ist Benutzerfreundlichkeit wirklich nicht gegeben? Das kommt wohl auf den Betrachter an.

[volschin]

Ein wenig Suchen kann erlaubt sein und es ist nichts einfacher, als STRG+F zu drücken und nach "update" zu suchen. Ist Benutzerfreundlichkeit wirklich nicht gegeben? Das kommt wohl auf den Betrachter an.

Da bin ich mal gespannt auf dein Ergebnis mit  STRG+F in der "Device specific help". Ich glaube nicht, dass das anders als meins ausfällt. 

[marvin78]

Dass ich die commandref gemeint habe, weißt du (wenn man sich nicht auskennt, sollte man mAn IMMER die commandref zur Hilfe nehmen und darin suchen). Wie ich schon schrieb, würde ICH nicht in global suchen, wenn ich das Modul update konfigurieren möchte. Meine Logik muss man aber nicht teilen. Ich habe dir ja zugestimmt, dass es nicht ganz konsequent ist, dass die Attribute in gobal nicht beschrieben werden. Wobei auch das auf die Betrachtungsweise ankommt.

[Elektrolurch]

Hallo,

Zitat:
Ein wenig Suchen kann erlaubt sein und es ist nichts einfacher, als STRG+F zu drücken und nach "update" zu suchen. Ist Benutzerfreundlichkeit wirklich nicht gegeben? Das kommt wohl auf den Betrachter an.

Ja, ist nicht gegeben! leider ist das nicht immer so einfach, ich fühle mich jetzt diskreminiert.. :_)

Mal im Ernst: Wenn ich versuche im Browserfenster in der Command-Ref (ein Riesenfile) mit strg+F was zu suchen, findet der Browser ev. etwas, aber leider steigt mein Screenreader aus, denn er springt nicht an die gefundene Stelle. Im Ergebnis: im Broserfenster mag es ev. stehen, der Screenreder liest aber die alte Position vor und sobald ich eine Navi-Taste drücke, springt der Broser auch wieder an die alte Stelle zurück.
Grund ist hierfür das zu große html-File der Command-Ref.

Und im Übrigen mal: Die Suchmaschine in fhem findet ja auch so gut wie nichts. Meist suche ich über google mit Einschränkung auf site fhem und dann finde ich mehr, als über die Suchmaschine in fhem.
Der hier häufig von den "Freaks" angeführte Hinweis: Steht ja alles im Forum, ist daher nur bedingt hilfreich, wenn die Tools nicht das tun, was man von ihnen erwartet.

Elektrolurch

[marvin78]

Naja. Ich nutze auch nur google für die Suche im JEDEM Forum. Ich kenne keine Forensoftware mit brauchbarer Suchmaschine. Der Hinweis auf das Forum ist sicher sehr hilfreich und gut, wenn es wirklich drin steht. Ich sehe da kein Problem. Googlen ist nun wirklich nicht zu viel verlangt.

Dass die commandref in der Form eventuell nicht für Screenreader geeignet ist, mag sein und ist das ist sicher auch der Benutzerfreundlichkeit für gewissen Nutzergruppen nicht zurträglich. Für andere macht die Tatsache, dass es eine html Seite ist, es eben doch am leichtesten durchsuchbar. Wenn die HTML Seite zu groß ist, stellt sich die Frage, ob es an der commandref oder am Screenreader liegt, dass das nicht gut funktioniert. Ich kenne mich mit Screenreadern nicht aus, deshalb kann ich dazu nichts sagen. Wenn der Screenreader es nicht kann, weil es technisch nicht möglich ist, sollte man evtl. sehen, wie man die commandref technisch verbessern kann, da stimme ich zu.

Diskriminiert habe ich dich jedoch sicher nicht. Ich schrieb ja: "Es kommt auf den Betrachter an". Benutzerfreundlichkeit ist eine sehr subjektive Sache. Beispiel: Ribbon Oberfläche in MS Office. Wer das "alte" Office gewohnt war, fand sich zunächst nur schwer zurecht und fand häufig nicht viel wieder. Wer damit neu einstieg sprach von einer sehr guten Usability.

[Elektrolurch]

diskreminiert:
hatte ja auch ein angehängt!

[marvin78]

Nun. Smileys werden nicht von jedem verstanden und ich wollte das weniger für dich, als für andere klarstellen.

[rudolfkoenig]

Ich finde das commandref langsam auch zu gross (en:1.7MB, knapp 1000 "Seiten"), habe aber noch keine gute Idee, wie man das verbessern koennte, ohne die Sache deutlich komplizierter zu machen (z.Bsp. Suchmaschine in FHEM einbauen) oder Features zu verlieren.

Das urspruengliche Problem liegt daran, dass Befehle wie backup oder update keine Detailseite haben, und deswegen das "Device specific help" nicht hilft. Auch deswegn sind mir solche Komandos ein Dorn im Auge, und ich haette lieber ein update- und backup-device,
was man einzeln konfigurieren kann.

Beim Thema "Benutzerfreundlich" gibt es noch die Dimension Einsteiger/Experte, d.h. man kann es in vielen Faellen nur mit der doppelter Arbeit beiden Recht machen.