[linux-l] mbox/Maildir/tar

[Oliver Bandel]

Zitat von Steffen Dettmer <steffen at dett.de>:

> * 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.
[...]
[...]
> > Also passt es.
>
> Gut, halten wir fest, es gibt einen Fall in dem atime > mtime
> funktioniert... grpmf
>


Stimmt.
Nun brauchen wir noch Möglichkeiten zum Detektieren
der anderen Fälle ;-)




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

OK, also die Sache mit dem Backup seh' ich ein.
Bei den anderen Fällen denke ich, daß die
Tools, die speziell sich mit dem Mailzeugs
beschäftigen, also reader und biff und so,
sollten da IMHO alle so arbeiten, daß sie sich
nicht gegenseitig den Status "neue Mail ist da"
kaputt machen.

Bleibt noch der Backup-Fall.


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

Stimmt, naja, also, was den Zugriff angeht, da
fällt mir ein, daß ich selber manchmal ein "cat" auf eine Mailbox
ansetze, oder mit vi rein schaue. (Ich weiss ja, wann die
mboxes beschrieben werden und wann nicht, also es gibt mit Schreibern
keine Kollisionen).

Damit würde ich mir ein "neue Mail ist da" quasi kaputt machen,
wenn es sich nur auf die atime verlässt.

Ich weiss dann aber bereits, daß neue Mail da ist,
da ich sie schon gelesen habe, nur halt nicht mit mutt.
Also stimmt es auch, daß das in diesem Falle kein Problem ist. :)

Bleibt aber noch der Backup-Fall, da hast Du recht.

Vielleicht sollte man das Backup dann atime-neutral gestalten...


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

weiss ich nicht.


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

OK, eigentlich ja.
Aber typisch ist das nicht, oder. ;-)



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

Wieso muss man beim Hash vom Inhalt zum Key kommen?
Wenn man Hash perlish benutzt, was ich tat, womit ich wohl
informatik-mäßig falsch gesprochen habe, weil ich das
reserved Keyword "Hash" falsch benutzte, dann habe
ich damit ein assoziatives Array gemeint.
Dann meinte ich nich teine Funktion, die wie bei md5sum aus einem
Inhalt auf einen Key schliesst.

Wie der Key intern verwaltet wird, ist mir egal. Das wird mir
weg abstrahiert. Ich gebe einen Namen als Key und sage
was die Value ist. In Perl nennt man sowas Hash.

Also benutzt Perl an auch eine Sprache, die einem Informatiker
nicht gerecht wird?

Welches Keyword hat denn hier Vorrang?
Gibt's da nen Standard, oder zählt, was üblich ist?
Dann wäre
 perlish die richtige Variante und wer "Hash" als Funktion
zur Schlüsselgenerierung meint, liegt damit falsch.
 ==> Informatiker-Fachsprache in die "das ist unüblich"-Tonne

Genauso benutzt man auch einen Dir-Entry: man hat nen Key und eine
Value. Key ist der Filename, Value der Inhalt des Files.

Und da muss ich vom Inhalt nicht auf den Key kommen,
ebensowenig wie bei einem assoziativen Array.



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

häh?


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


Nicht mehr so oft, aber vielleicht sind das die spätfolgen
aus meiner Kindheit ;-)

Gruß,
   Oliver