[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

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

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

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?

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

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

$ l -lu B
-rw-------    1 steffen  users        2708 2007-11-29 14:15 B
$ date
Sam Dez  1 02:18:45 CET 2007
$ echo >> B
$ l -lu B
-rw-------    1 steffen  users        2709 2007-11-29 14:15 B

unverändert, aber:

$ tail B
[...]
$ l -lu B
-rw-------    1 steffen  users        2709 2007-12-01 02:19 B

gelesen --> aktuell.

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

Kann ich nicht nachvollziehen.

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

Meine Idee ist fast trivial einfach und doch dermassen offensichtlich,
dass ich vermute, dass es einen Grund gibt, warum man es so nicht macht,
meine Idee also gerade nicht besser ist. Ich seh ihn nur leider nicht.

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

atime > mtime auch nicht, wenn ich eine Mail lösche (trunc), wird atime
auch nicht aktualisiert. (Gut, hab ich jetzt nicht getestet, weil ich
kein trunc mit shell hinkriege).

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

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.
Der Zustand ist aber lokal und nicht persistent. Für ein oldstyle
`mail', was man oft geöffnet und geschlossen hat, würde ich das ja noch
verstehen (nämlich wegen der Persistenz), aber bei einem MUA der pro
Mail den Lesezustand verwaltet etc?

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.

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

Ja, das meiste ist ja eben schon implementiert :)

[locking]
> >Damit ist mbox+ und Index eine logische Resource.
> 
> Ja, das habe ich verstanden. Aber Locking würde besser schützen.

warum bzw. in welchen Fällen? Hängt es in beiden Fällen nicht einfach
davon ab, ob alle es richtig machen (locken)?

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

Bleibt die Frage, ob es richtig ist, überwiegend Kompression zu
benutzen, obwohl man vielleicht gar keine will? Weil das "z" schon
gewohnheitsmässig in das "tar cf" rutscht? Ich kriege auch jpegs in
rars oder so. Nicht wegen der Kompression sondern aus allen möglichen
anderen Gründen. Meist tut die Kompression ja nicht weh und ist damit
eigentlich prima, find ich, aber wenn ich nu wirklich immer eines der
letzten 5 Files aus einem 300k files archiv mit 10 GB Grösse suche, dann
mache ich vermutlich was falsch :-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.