[linux-l] mbox/Maildir/tar

[Rocco Rutte]

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

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*

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

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

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.

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.

>Aber das Problem der falsch-Implementierung hast Du doch
>immer!

Ja.

>Man kann auch Daten aus $MY_MAILDIR/myfolder/tmp
>lesen, wenn man will, oder da auch wüst drin rum schreiben.
>Man kann auch in einer mbox, in die alles hinein läuft,
>Unsinn anstellen.
>Man kann auch diverse andere supertolle Formate sich ausdenken
>und wieder kommt einer, der es falsch macht.

Ja.

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

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.

Wie soll man sowas auch sicher lösen, wenn Locking im Spiel ist? 
Richtig: IMHO gar nicht. :)

MfG, Rocco