[linux-l] mbox/Maildir/tar

[Rocco Rutte]

Hi,

* Steffen Dettmer wrote:
>* Rocco Rutte wrote on Wed, Nov 28, 2007 at 22:26 +0100:
>> >> Man kann definieren, dass eine mbox-Mailbox ungelesene Nachrichten
>> >> hat, wenn mtime > atime. 

>> >Macht das etwa jemand?! Das geht ja schon kaputt, wenn zwei Prozesse das
>> >File überwachen!

>Nochmal warum es nicht funktioniert:

>- proc A und proc B überwachen.
>- proc C schreibt neue mail
>- proc A stellt fest, mtime > atime
>- proc A liest Änderungen (setzt atime)
>- proc B merkt nichts, weil atime schon wieder neuer

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

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.

>> Und ja, mutt macht das schon immer so. 

>wahh, tatsächlich, Hammer!

?!

Ich behaupte immernoch: Das ist der einzig sinnvolle Weg. :)

>Ich hab jetzt ne Stunde oder so gegoogelt und rumgelesen und ausser
>Problemen mit diesem Verhalten nichts gefunden, insbesondere nicht,
>warum man auf diese Idee kam.

Weil es die zuverlässigste ist?

>Wenn ich wissen möchte, ob sich ein File geändert hat, seit ich es
>gelesen hab (Zeitpunkt X), prüfe ich doch, ob dessen mtime neuer ist als
>Zeitpunkt X?! Wie kommt man darauf, die atime zu verwenden? Was ist,
>wenn ein anderer Prozess das File auch liest?

Letzteres: s.o., dann gibt es keine neue Mail.

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

Das einzige was jetzt noch übrig bleibt ist die Tatsache, dass mtime 
größer atime heisst, dass irgendjemand geschrieben hat nachdem jemand 
das letzte Mal gelesen hat. An der Stelle muss man es aber leider diesem 
"jemand" überlassen, dafür Sorge zu tragen, die neue Mail richtig zu 
behandeln (Signal irgendwohin, utimes(), etc.)

Wenn du eine bessere Idee hast, send Patches... :)

>> Es ist es auch der mit Abstand schnellste Weg, es gibt keine
>> Alternativen. 

>Ich hab sowas schon in etlichen Scripten gemacht. Ich hab mir immer
>mtime gespeichert, das file gelesen und dann gewartet, bis mtime >
>last_mtime wurde. Was ist daran falsch/schlecht/langsam?

Es wirklich num um _neue_ Mail. Da sagt die mtime leider nichts aus.

>> Die Dateigröße geht nicht, komplett MIME-parsen dauert
>> zu lange und müsste blockieren. Für Systeme mit kaputter atime hatte
>> mutt früher eine compile-time Option, die mittlerweile runtime ist
>> (auf ftp.mutt.org sollte noch irgendwo fixatime.c rumliegen für cron).

>ja, hab ich gefunden. Grösse ist meiner Meinung genauso falsch, wenn
>eine neue Mail mit 2K reingeht und eine andere mit 2K gelöst wird,
>bleibt die Dateigrösse ja konstant.

>Ist mutt ein Highlander?!

>Haut mich völlig vom Hocker, so einen Korken in mutt zu finden, dachte
>immer, mutt `macht alles richtig'. Komisch. 

>Weiss jemand, warum man das mit dem atime macht?

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

Wenn du mich fragst kann man das schon theoretisch nicht korrekt 
implementieren.

>Nein, eben nicht /immer/. Hat man grosse Dateien, ist mbox langsam, weil
>man (ohne index, was ja mbox erstmal nicht hat) ja u.U. Megabytewise
>MIME Anhänge parsen müsste, um die nächste Mail zu finden.

Stimmt. Aber ich lasse mutt hier Anhänge zählen, also muss er bei so 
oder voll MIME-parsen. Gut, das meiste dann erst im Index, nicht schon 
beim Öffnen.

>Letzters kommt IMHO maildir schon recht nahe. Man hat
>Nachrichtenobjekte, paar Flags/Zustände, aber viel mehr eigentlich
>nicht. Die Operationen erzeugen, löschen etc. sind
>Dateisystemoperationen, das Juhunix kümmert sich darum, dass das
>funktioniert. Eigentlich ist doch ein Filesystem genau dafür da. Macht
>Squid `in diesem Sinne' genauso. Hat irgendwie etwas, finde ich.

Und nicht zu vergessen: Es ist trivial zu implementieren.

>Warum muss man die mbox+ (ich nenn das mal anders, weil mbox mit Index
>ist ja nicht mbox, weil mbox kennt sowas ja nicht) locken? Man kann doch
>definieren, dass man die Index immer lockt, das gilt dann immer für mbox
>mit. Theoretisch könnte man die mbox lesen wollen ohne index zu lesen,
>aber dann muss man laut dieser Konvention halt trozdem den Index locken.
>Damit ist mbox+ und Index eine logische Resource.

Ja, das habe ich verstanden. Aber Locking würde besser schützen.

>> Aber selbst dann muss alles erst entpackt werden, weil ja das tar-File 
>> als solches komprimiert wird. 

>Na ja, wenn man es nicht komprimiert haben möchte, weil es eine
>Bandsicherung ist, komprimiert man es einfach nicht, oder? Das mal
>unabhängig von dem Problem.

Ja. Hätte man beim Container auch. Aber da ich mal behaupte, dass 
überwiegend mit Kompression benutzt wird und die Kompression eigentlich 
nur über Unix-Methoden aber nicht vom Format herkommt, ist das schon 
manchmal ein Problem.

MfG, Rocco