[linux-l] mbox/Maildir/tar
Oliver Bandel
oliver at first.in-berlin.de
Do Nov 29 14:40:11 CET 2007
Moin,
Zitat von Rocco Rutte <pdmef at gmx.net>:
> Hi,
>
> * Oliver Bandel wrote:
> >Zitat von Rocco Rutte <pdmef at gmx.net>:
> >> * Oliver Bandel wrote:
> >>>Zitat von Rocco Rutte <pdmef at gmx.net>:
>
> >>>> [ mbox mit Index ]
>
> >> Alles, was zusätzlich Indizes braucht kann nur über eine
> >> MDA-Abstraktion gelöst werden, sonst geht es früher oder später
> >> kaputt.
>
> >MDA-Abstraktion?
> >Was meinst Du?
>
> Eine Mailbox-Treiber Library (z.B. c-client), die das Mailhandling
> zentral betreibt und die alle benutzen müssen.
hahahah, also doch locking: Der Tool-Programmierer und User
wird gelockt: "Gehen Sie nicht über Los, ziehen Sie keine xx euro ein,
begeben Sie sich direkt dorthin!".
Die Voraussetzung ist wieder mal: alle müssen sich dran halten,
sonst klappt es nicht.
Ist also auch kein Fortschritt.
Im Gegenteil: Du sprachst ja von möglichst obskur und
BlackBox. Heheh. Am besten noch ohne Sourcen, ja?
Jetzt weiss ich, wieso bei M$ die Mailer alle gut funktionieren ;-)
(Safe) functionality by obscurity...
... or by prison.
> Das können MUAs sein
> oder
> auch ein Tool, das von stdin Mails liest und sie sauber in den
> Mailspool
> committet, ohne ihn kaputt zu machen.
Ist ja wunderschön.
Das ist aber letztlich auch nicht unbedingt sicher.
Bringt das also wirklich Vorteile?
Wenn schon, dann muss ein eigener User her und ein
Serverprozess, der die Sachen entgegen nimmt.
Dann kommt (wenn Persissions richtig gesetzt)
nur de Mailverwalter da dran.
>
> Im Optimalfall ist das Format nur im Source dokumentiert und
> hochgradid
> obskur (Blackbox), damit niemand sonst versucht das zu implementieren
> und man auf die Library gezwungen wird... *g*
Ja, wir machen dann das Licht aus und eine kleine Funzelkerze an
und sprechen beschwörende Formeln ;-)
>
> >> Das Problem ist, dass dir niemand garantieren kann, dass das File
> zum
> >> Zeitpunkt des Lockens das File exakt den Inhalt hast, den du
> >> erwartest.
>
> >Häh? Was meinst Du damit?
>
> >Wenn das File den Inhalt hat, den ich erwarte,
> >weiss ich schon was drin steht.
>
> >> Und selbst wenn du das für deine Software garantieren kann,
> >> irgendjemand
> >> implementiert es immer falsch. :)
>
> >Ach so, jetzt seh' ich, worauf Du hinaus willst.
>
> Nein, offensichtlich nicht. :) Betrachen wir die zeitliche Abfolge:
[...]
Stimmt, das hätte ich jetzt nicht erwartet ;-)
Da war ich wohl in nem anderen Film.
>
> 1) Client A liest mbox mit locking, gibt Lock frei
> 2) Client A will etwas ändern und bereitet sich auf Schreiben vor
> 2) Client B holt sich Lock, schreibt, gibt Lock frei
> 3) Client A holt sich Lock und schreibt
Falsche Reihenfolge.
Was ist denn damit gemeint bei 2) mit
"bereitet sich auf Schreiben vor"?
Wieso macht A das Locking erst später?
Nixe gut, das.
>
> Im besten Fall sind die Änderungen von Client B nur weg; wenn einer
> von
> beiden versucht das Schreiben durch Seeking zu optimieren, ist die
> mbox
> kaputt, weil in 3) Client B selbst mit Locking schreibt und Client A
> nicht merkt dass sich zwischen 1 und 3 was geändert hat.
Dumm, wenn er das nicht gemerkt hat.
Sollte er besser ;-)
>
> Selbst wenn man das sauber implementiert bekommt, in dem man immer
> komplett Locking betreibt, hat man noch das Problem, dass andere
> Tools
> das Locking nicht sauber machen.
Hmhhh, nun ja, das dachte ich meintest Du auch da oben.
Daß Dir Deine Daten zermanscht werden kann doch
aber auch bei Maildir passieren.
Man braucht kein Locking um was kaputt zu machen ;-)
[...]
> >Wie also willst Du dieses Problem lösen?
> >Du scheinst ja eine Idee davon zu haben, wie
> >es gehen soll?! Was schlägst Du vor?
>
> Man nimmt einfach Maildir. Da kann zwar immernoch alles furchtbar
> kaputt
> gehen, aber (!):
>
> 1) Wenn, dann nur einzelne Nachrichten. Der Rest bleibt zu 100%
> parsebar, weil es keine Message-Boundaries gibt, die durch einen
> Unfall
> kaputt gehen können (Maildir: Boundary == EOF, wenn das kaputt ist,
> hast
> du ganz andere Sorgen... :) Gleiches gilt für irgendwelche Indizes
> mit
> Byte-Offsets und dergleichen.
>
> 2) Da korrekte Clients nahezu zufällige Dateinamen generieren geht
> die
> Chance der Katastrophe nahezu gegen 0. Auch mit kaputten Clients ist
> die
> Chance sehr gering. Man kann höchstens noch Kollissionen
> provozieren/ignorieren, dann gilt aber 1).
hmhhh
>
> Betrachtet man 2) können bei Maildir ohne Index nahezu beliebige
> Tools
> auf dem Spool rumschhreiben wie sie wollen, und zwar völlig ohne
> Locking. Tools sind dann auch tar, cp und Konsorten.
>
> _Das_ bietet kein anderes Format und kann es nicht, sobald Locking
> notwendig wird. Selbst der MDA-Ansatz ist nicht gegen rsync, unison,
> tar, cp, etc. immun; Maildir schon. _Und_ das ganze noch halbwegs
> sicher
> NFS.
Hmhhh.
Du plädierst also für "Maildir" mit Inode-Sort?
Ciao,
Oliver
Mehr Informationen über die Mailingliste linux-l