[linux-l] mbox/Maildir/tar
Steffen Dettmer
steffen at dett.de
Sa Dez 1 15:48:38 CET 2007
* Rocco Rutte wrote on Sat, Dec 01, 2007 at 13:12 +0100:
> * Steffen Dettmer wrote:
> >Das ist doch aber nicht dass, was man will (oder)? Dann würde ja mutt
> >die atime auch nicht zurücksetzen. Wenn ich zwei mutts aufhabe, sollen
> >doch natürlich beide merken, dass neue Mails da sind.
>
> Solange man nicht sync macht, sollten es auch das zweite merken, oder?
Doch natürlich, auch wenn nicht gesynct wird; ob die Daten im
buffercache sind oder nicht, darf ja ein Prozess nicht merken, also
Änderungen sind sichtbar, auch wenn physikalisch noch nicht geschreiben
(weil der andere Prozess ja aus dem Cache liest, in den der erste
geschreiben hat). Oder meintest Du was anderes?
> Aber die Zeiten könnten bei sync weg sein, weil mutt beim Umkopieren der
> mbox die Zeiten Originals beibehält.
d.h., es wird die atime und mtime sozusagen `zurückgesetzt'?
Interessant. Komisch, wenn man sowas braucht /und/ sich auf Änderungen
dieser Zeiten bei neuen Mails etc. verlässt, hinkt doch irgendwas, oder?
> Wenn man aber open()+read() benutzt bei mbox muss man als Entwickler
> wissen, dass womöglich alle anderen Tools über die Infos aus stat()
> gehen und muss Maßnahmen ergreifen bzw. sollte genau über die
> atime/mtime nachdenken. Mutt zum Beispiel behält die Zeiten bei/setzt
> sie entsprechend in dutzenden Situationen (z.B. wenn es bei einem Folder
> den Typ prüft, weil open()+read() die atime verändern).
Na ja, aber wenn man die atime `fälschen' muss, kann doch irgendwas
nicht sauber sein, oder?
> >Es kann ja ein Backup gewesen sein. ICH erwarte jedenfalls, dass mein
> >mutt neue Mails anzeigt, selbst wenn die Mail vom Backup schon "gelesen"
> >wurde (wobei gelesen heisst, dass sie auf Band geschrieben wurde).
> >Erwartet jemand, dass Mails/mboxes, die aufs Band geschrieben wurden,
> >als gelesen auftauche / keine neuen Mails enthalten?
>
> Der "Hack" über mtime größer atime ist nur für als Benachrichtigung.
> Wenn ich Mailbox A offen habe und B vom Band zurück auf die Platte
> geschrieben wurde, dann reden wir nur darüber ob mutt neue Mails für B
> anzeigt oder nicht. Je nachdem wer das wie zurückschreibt könnte es das
> auch, das habe ich aber nie probiert (Dump: atime/ctime über stat()
> auslesen, dann erst öffnen und wegschreiben, Restore: erst
> zurückschreiben, dass atime/ctime setzen; die atime/ctime-Kombo müsste
> wieder stimmen).
mmm.. Hört sich für mich alles ein bisschen komisch an. Vielleicht weil
ich es nicht richtig verstehe, oder weil es ein `Hack' ist... Ich
verwende nur maildir, nur eine mutt Instanz (mehrere procmail, klar :))
und habe glücklicherweise keine Probleme - ist ja nach dem, was ich
gelesen hab, ein Grund zur Freude :)
Wenn ich mutt neu öffne, muss mutt ja eh parsen, um zu wissen, ob
irgendo ungelesene Mails drin sind. Oder funktioniert es anders,
vielleicht, weil es Leute gibt, die anderes Verhalten erwarten? Bei
maildir ist das jedenfalls so. Enthalten mailboxes ungelesene Mails, ist
er `N'. Liest man alle und kommt dann was dazu, `merkt' mutt das. Das
hat manchmal sogar Nachteile (wenn im Hintergrund fetchmail läuft,
ändert sich ständig was und man kann u.U. eine Mailbox kaum verlassen).
> >Ich versteh das nicht...
>
> Doch, mutt will genau wissen ob *irgendjemand* was gelesen hat oder
> nicht, mutt parsed da gar nichts (außer mit dem sidebar Patch). Wozu
> auch, es geht ja nur darum ob es unten in der Statuszeile sagt "New mail
> in...", mehr nicht, also nur um den biff-Teil. (Und nebenbei ist es
> nicht so schlimm wenn der mal nicht richtig funktioniert)
New mail muss doch auch da stehen, wenn jemand anders (aber nicht mutt)
die Änderungen gelesen hat. Dann hat jemand anders benachrichtigt (oder
was auch immer), aber mutt noch nicht.
> Und da scheiden alt-neu-Vergleiche der mtime aus, weil man nicht auf
> ungelesene Nachrichten schließen kann, ebenfalls für atime-Vergleiche.
> Also bleibt ja nur noch atime-vs-mtime.
> >atime ändert sich doch überhaupt nicht, wenn neue Mails geschrieben
> >(angehängt) werden:
>
> Eben! Also hast du es ja doch verstanden!? :-) Eben weil sie sich beim
> Schreiben nicht ändert aber die mtime schon, schließt mutt, dass es
> genau dann ungelesene Nachrichten in einem x-beliegen Ordner gibt, wenn
> sie noch _keiner_ gelesen hat.
Wieso, man kann sich doch nicht drauf verlassen, ob neue Mails appended
werden oder gar vorn angehängt werden oder mittendrin einsortiert
werden? Oder ist das eine Annahme? Neue Mails nur via append? Aber dann
könnte man ja doch Grösse nehmen, wenn eh nur append erlaubt ist?
> >na hab ich doch geschrieben, via mtime um die Änderungen zu erkennen.
> >Man nimmt dann dazu nicht atime sondern die mtime, bei der man selbst
> >zuletzt gelesen hat. Ist man der Einzige, sind beide natürlich gleich.
>
> ...und hat Client B eine Mailbox offen und ändert ein Keyword einer Mail
> und speichert die Änderung, sagt Client A es sei neue Mail in Mailbox,
> weil die mtime unterschiedlich ist.
Nein, dann weiss client A, dass es Änderungen gab und kann neu parsen.
In dem Fall klappt ja mtime > atime auch nicht, weil wenn Client B eine
Mail hinzufügt /und/ ein Keyword ändert, würde Client A es ja /nicht/
merken!
> >Aber erstaunlich, wie komplex das Thema ist. Daher glaube ich auch kaum,
> >dass man so einfach und nebenbei etwas wesentlich Besseres hinkriegen
> >würde, da haben sich sicherlich schon viele schlaue Leute einen Kopf
> >drüber zerbrochen.
>
> Ja. Das Problem ist zu erkennen ohne zu Lesen, nicht nur ob überhaupt
> etwas geändert wurde sondern auch noch was (neue Nachrichten).
mmm... ohne Lesen... Ich glaube, das geht einfach nicht. Man kann
Annahmen machen, wenn die zutreffen, kann man vielleicht abkürzen, man
kann sich aber auch die Karten legen...
Bei Maildir kann man mtime vom Verzeichnis überwachen und es neu
einlesen. Gut, wenn man 300k mails in new/ hat, wird das schlimm...
> Es kann auch schon theoretisch nicht funktionieren ohne volles Parsen
> der mbox. Man kann ja auch eine gelesene Nachricht an einen Ordner
> anhängen, dann gilt atime<mtime immer noch...
ohh ja, ist ja ein noch gemeineres Beispiel... Hier könnte man sich
streiten, ob das nicht richtig ist, es als neu anzuzeigen. Die Mail ist
sogesehen ja neu. Anders gesehen aber auch wieder nicht. mmm... lol
gemein
mmm... was ist nun die Moral von der Geschicht? maildir nehmen, weniger
als 10k mails drin haben und alles geht? (so mache ich das hier). Ist
natürlich arbeitsam und hat auch Nachteile (... wo ist den die letzte
Mail zum Thema XYZ nu hin ...).
All mail clients suck. This one just sucks less.
:-)
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
Mehr Informationen über die Mailingliste linux-l