Gruesse! * Andreas Pakulat <[EMAIL PROTECTED]> 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... -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
