Re: Muttng's Listen-Verhalten und Header Cache
Gruesse!
* Andreas Pakulat <apaku@gmx.de> schrieb am [31.05.05 12:48]:
> On 31.Mai 2005 - 12:10:10, Gerhard Brauer wrote:
>
> > Will sagen: ein gestartetes mutt-ng kann mit Sicherheit auch nur jeweils
> > die Cache-Datei-Art lesen+schreiben, die auch beim Anlegen des Caches
> > aktiv war. Also compressed oder uncompressed.
>
> Wieso? Wenn dem so ist: Wieso steht das nicht im Manual? Wieso kann
> mutt-ng bzw. die qdbm einen unkomprimierten Cache nicht komprimieren?
Weil es ihn wahrscheinlich garnicht einlesen kann. Aber das ist nur
eine Vermutung meinerseits. Ohne Blick in den Source wird das nicht
befriedigend zu klären sein - und da bin ich der Falsche.
>
> Oder ist es so, dass mutt-ng nicht erkennen kann ob ein header_cache
> komprimiert oder unkomprimiert ist (ausser ueber die entsprechende
> Einstellung)? Aber wenn dem so ist, duerfte der Cache ja "invalid" sein
> wenn ich von komprimiert zu unkomprimiert schalte (oder umgekehrt),
> wieso baut er den Cache nicht neu auf?
Das ist in der Tat eine berechtigte Frage. Ich werde das bei mir heute
Abend auch nochmal testen. Interessant wäre da v.a. ob der (defekte)
Cache (komprimiert oder unkomprimiert) überhaupt ausgewertet bzw.
angefaßt wird. Sehen können müßte man das mit einem strace bzw. an der
mtime der cache Dateien. Merken werde wohl nur ich es, das bei dir das
cachen ja subjektiv wenig an Zeitersparniss bringt.
> Fragen ueber Fragen, nicht boese sein aber diese Implementierung sieht
> mir nach Beta-Status aus :-(
Ich bin dir nicht boese ;-) Ich denke eher, du bist in einen
Grenzbereich des Programmierers vorgedrungen, in dem schnell ein Fehler
(bug) passieren kann. Vorstellbar wäre da z.B. das mit Sicherheit zwei
Mechanismen existieren, nennen wir sie mal read_cache, die entweder in
mutt_ng selbst bzw. über Routinen in der qdbm implementiert sind.
Dort wird über die Config-Variable entschieden, ob die cache-Datei (oder
der Datensatz) vorm Einlesen noch dekomprimiert werden muß, oder nicht.
Und wenn die cache Datei (über einen Header z.B) nicht hergibt, ob diese
un-/komprimiert ist passiert ein Fehler. Und wenn dann dafür keine
Fehlerroutine eingebaut ist...wäre es *möglich*, daß das caching
vollkommen übergangen wird bzw. irgendwelche Seiteneffekte hervorruft.
Aber das ist Spekulation. Ich denke, wenn sich mein Versuch heute abend
ebenso verhält solltest du einen Bugreport schreiben. Weil das Wechseln
zwischen beiden Caching-Methoden eigentlich ncihts Ungewöhnliches ist
(Elmar hat ja z.B. in einer Mail dazu geraten). Wenn der Anwender dann
in so einen Fehler läuft, der mit durchschnittlichem Wissen (also
händischem Löschen des alten Caches) nicht lösbar wäre, dann ist das ein
Fehler im Programm, das nicht abzufangen.
> > Wenn du dich aber für *eine* der beiden Varianten entscheidest, dann
> > geht es doch?
>
> Jepp, die wichtigste Frage ist eigentlich: Wenn ich das umstelle und der
> Cache dadurch ungueltig wird, wieso wird er nicht neu angelegt.
> Andersrum wenn der Cache nicht ungueltig ist (also weiterhin gelesen
> werden kann von muttng), wieso hab ich dann die Probleme?
Wie gesagt, Vermutung: weil jeweils nur Müll im cache-struct steht.
Statt header.cache.subject="Mutt ist geil!" vielleicht nur
header.cache.subject="#34f#.439" (komprimiert halt). Dann funktioniert
latürnich der Abgleich cache<->Original nicht mehr und produziert evtl.
den von dir beschriebenen Fehler mit den replys, weil die inhaltliche
Korrektheit des Caches zu diesem Zeitpunkt nicht überprüft werden kann.
>
> Andreas
Gruß Gerhard
--
Der schwarze Ritter ist unbesiegbar...
Reply to: