[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Oliver Bandel wrote on Thu, Nov 29, 2007 at 19:16 +0100:
> Zitat von Steffen Dettmer <steffen at dett.de>:
> 
> > * 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.
> 
> 
> Schön.
> 
> Normalerweise ist das mbox-Locking aber notwendig, nicht weil mehrere
> Lesen und einer Schreibt, sondern weil einer liest und mehrere
> möglicherweise Schreiben.

In diesem anderen Fall funktioniert atime > mtime ja `zufällig'. Daher
habe ich ja diesen Fall (der der ist, der zu der Diskussion und damit
dem Beispiel führte) gewählt.

> Das, was Du da schön beschrieben hast, ist also nicht der Fall, der
> auftaucht, wenn Dein Mailreader neue Mails meldet und mehrere Mails
> Dir z.B. über mehrere Procmails in die Boxes schreiben.

Das ist ja auch korrektes Verhalten. (?) Auch bei mehreren neuen Mails soll
der Mailreader neue Mails melden, klar.

> Also wird die atime auch nur vom (vom = von dem einen) Mailreader
> geändert, die anderen (die Schreiber) ändern die mtime.
> 
> Also passt es.

Gut, halten wir fest, es gibt einen Fall in dem atime > mtime
funktioniert... grpmf

In meinem Beispiel funktioniert es aber nicht, weil MUA B (oder biff
oder was auch immer) nicht anzeigen wird, dass neue Mails da sind.
Vielleicht ist auch A das backup und B der MUA.

Natürlich gibt es nach C auch D und E, die schreiben (procmails oder
sowas), klar.

> [...]
> > 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?
> [...]
> 
> Warum sollte ein anderer Prozess da die Files auch lesen?

? lol

ja warum denn nicht, es gehört doch nicht dem MUA B. Wie kann MUA B
fordern wollen/dürfen, dass nur er das lesen darf?!

> > Nein, eben nicht /immer/. Hat man grosse Dateien, ist mbox langsam,
> > weil man (ohne index, was ja mbox erstmal nicht hat)
> [...]
> 
> mbox hat keinen Index.
> Aber mbox hat auch keine Statusflags im Header.

mmm... macht aber das gute alte Ur `mail' genau so, oder?

> > Eigentlich ist es ja durchaus elegant, das Filesystem als Index zu
> > benutzen.
> 
> Stimmt.
> Ist eine Möglichkeit, wie man schnell zu einem Ergebnis kommt.
> Nennen wir es wohlwollend Rapid Development.

Ich würde es schlicht `Development' nennen, weil Wiederverwendung ja
dazugehört ;)

> > Ich meine, dafür ist es ja da! Es gibt Resourcen (u.A.) Namen, man
> > dann da was lesen/schreiben - genau, was man hier braucht und bei
> > maildir ja verwendet wird.
> 
> Ja, sozusagen ein Hash :)
> Filename ist der Key und Inhalt ist die Value.

Muss gar kein Hash sein, weil man vom Inhalt gar nicht zum Key kommen
können muss. Kann man eine Zufallszahl oder einen Zähler nehmen oder so.

> > Na ja, lokal mit flock oder fnctl locking funktioniert ja
> > (jedenfalls hatte ich früher, als ich sowas benutzt hatte, keine
> > Probleme im Falle ein procmail und ein PINE oder mutt), oder? So
> > theoretisch jedenfalls.  Nur halt nicht ganz immer...
> 
> Wieso "halt nicht ganz immer"?

Wenn es immer funktionieren würde, hätten wir das Thema ja nicht :)

> > Ja, das geht nicht. Man muss exklusiv locken und umkopieren, bei
> > jeder Änderung. Schreibt man Änderungen nicht sofort, muss man das
> > lock halten und kein anderer kann schreiben.
> 
> Eben.
> 
> Und da man auch keinen anderen Lesen lässt,
> dann verstellt sich auch die atime nicht.

Doch, die atime ändert sich ja gerade. Es wird ein neues tmp file
angelegt (neue atime). Dann das alte File kopiert (auch neue atime, aber
egal), dann neues file in altes umbenannt. Man hat neue atime (und ctime
und mtime).

> > ja klar, wer sich nicht an dsa locking hält... Aber wer sich nicht
> > daran hält, kann die Datei auch einfach löschen, ist's auch
> > kaputt...
> 
> Eben.
> 
> Das ganze $HOME wegmetzeln....

(guckst Du zuviel Fernsehen??? :))

> > > [ mbox mit Index ]
> > > >> Aber das Hauptproblem an dem Ansatz ist: jetzt hast du nicht 1x
> > sondern
> > > >> 2x Locking.
> >
> > 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

BTW, welchem Editor haben wir eigentlich diesen Formatierungsrekord zu
verdanken?  :) Ich schreib doch immer schon mit nur 72 Zeichen breite,
damit sowas nicht passiert...

oki,

Steffen

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