[linux-l] mbox/Maildir/tar

[Rocco Rutte]

Hi,

* Steffen Dettmer wrote:
>* Rocco Rutte wrote on Thu, Nov 29, 2007 at 16:47 +0100:
>> * Steffen Dettmer wrote:
>>>A und B sind natürlich wechselbar. Einer merkt es, der andere nicht.

>> Klar. Wenn Proc A die Änderungen liest, dann hat es jemand ja gelesen, 
>> ergo keine neue Mail. Es gibt da keine Unterscheidung zwischen Mensch 
>> und Maschine, gelesen ist gelesen. _Wenn_ aber jetzt jemand möchte, dass 
>> sein Lesen unbemerkt bleibt, dann _muss_ er auch was dafür tun.

>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? 
Aber die Zeiten könnten bei sync weg sein, weil mutt beim Umkopieren der 
mbox die Zeiten Originals beibehält.

>> Angenommen jemand würde auf die tolle Idee kommen eine schreibbare 
>> shared mbox-Mailbox zu betreiben. C wäre procmail, und A/B jeweils User. 
>> Wenn A die Mail vor B liest ist doch alles in Ordnung, weil es für B 
>> keine neue Mail mehr gibt.

>Für A ist die Mail ja noch neu. Ich rate mal, dass 90% der Leute
>erwarten, die Mail in dem Fall als neu angezeigt zu bekommen. Besonders,
>wenn diese Anzeige ein "notifier" ist, biff wäre glaub ich ein Beispiel
>(hab sowas nie benutzt) oder die Shell mit "you have new mail".

Ich habe sowas auch nie bentuzt. Solange die Notifier irgendeine Logik 
haben, die _nicht_ open()+read() benutzt, ist doch alles in Ordnung.

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).

>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).

>> Mutt benutzt den Check nur, um zu prüfen, ob es ungelesene Mail gibt und 
>> sagt das dem User, mehr nicht.

>> ctime scheidet aus. mtime scheidet ebenfalls aus, weil geänderte Mailbox 
>> nicht heisst, dass _neue_ Nachrichten da sind;

>mtime kann ja nicht ausscheiden, weil die bei dem Verfahren eine zentrale
>Rolle spielt. mtime > atime ist ja auch nach touch wahr, ist doch das
>gleiche. Daher frage ich mich ja, wozu man die atime will. Man möchte
>doch gar nicht wissen, ob *irgendwas* (backup etc) was gelesen hat,
>sondern ob der eigene Prozess das hat. Und wenn man was hat und wissen
>muss /was/, muss man eh parsen.

>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)

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.

>>  Parsen fällt wegen 
>> Locking und Aufwand leider aus. Größe scheidet auch aus, weil man Mail A 
>> mit Größe X löschen kann und man danach eine neue Mail ebenfalls mit 
>> Größe X reinbekommt, gleiche Größe kann aber trotzdem neue Mail 
>> bedeuten, unterschiedliche Größe nicht auch nicht. Bleibt atime. Die 
>> sagt aber erstmal nichts aus.

>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.

>> Die Frage ist nicht warum mutt das mit atime macht sondern wie man es 
>> sonst machen soll, siehe oben?

>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.

>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).

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...

MfG, Rocco