[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Oliver Bandel wrote on Thu, Nov 29, 2007 at 10:12 +0100:
> > Die flags stehen doch mittendrin! Daher muss ja soviel kopiert
> > werden, wenn eine Datei in der Mitte plötzlich ungelesen wird oder
> > umgekehrt.
> 
> Ach so, das habe ich vollkommen übersehen.  Ist nämlich nicht
> RFC-irgendwas, sondern <programm>-eigen.

(Na ja, die Felder stehen bei mbox halt im `header' der mail, ist schon
mbox-eigen, oder?)

> Über sowas denke ich eh schon eine Weile nach: Mailbox-Format mit
> fixed record length. Ist eine Mail länger als die Record-Size, nimmt
> sie halt mehrere Daten-Records in Anspruch.
> 
> Das wäre dann auch im Prinzip das selbe Format, wie ein indexed-tar es
> nutzen könnte, oder zumindest ähnlich.

ok. Die Einträge die 1..n records belegen, kann man `files' nennen. Dann
braucht man einen Index, der die Anfänge aller `files' zeigt, kann man
`directory' nennen. Dann Namen für Operationen: man muss ein `file'
erzeugen (`creat'), lesen (`read') und löschen (`unlink') können, dabei
muss der Index (`directory') automatisch aktualisiert werden. Nun kann
man das prima wiederverwenden, weil ist ja schon alles im Kernel
implementiert. :-)

Vielleicht hat man so maildir erfunden.

> > Ich hab das früher benutzt, mein MUA läuft meist die ganze Zeit. Mit
> > maildir läuft er `weiter' und sync ($ in mutt) ist schnell. Öffnen
> > ist langsamer. Kommt halt drauf an, was man macht.
> 
> Bis jetzt hatte ich mit mbox und maildir keine großen Probleme.
> 
> Ist die Frage, ob sich extra-Aufwand für Normalmensch-Mailerei
> lohnt. Und für nen Provider kann man dann ja mit Datenbanken
> was machen. Und irgendwo dazwischen gibt es vielleicht ein paar
> "Ich-habe-10GB-große-mbox-files"-user, die dann ein Problem haben. ;-)

Ja, sehe ich genauso! Für den Provider ist die Lage eben etwas anders;
hier kann der `grosse IMAP Server' ja im Prinzip machen, was er will und
cachen wie er Lust hat: er kann ja fordern, dass es lokal sein muss, nur
für Programme aus der IMAP package (da gibts dann ein deliver da drin)
zugreifbar sein soll usw., kann man auch sehr aufwändig machen, wie
gesagt, am Ende könnte jemand ne kleine Datenbank gebaut haben :)

Hat natürlich auch Nachteile bei bestimmten Operationen, Backup usw. und
Zugriff geht halt nur via IMAP etc, aber wenn man genau das braucht, ist
ja alles OK :)

> > `One Mail per mbox/File' kommt maildir ja schon recht nahe.
> 
> Stimmt.
> Ist aber was anderes, ob man die Mails vornehmlich als Archiv
> nutzt: das ist es, wenn ich sage: man ändert die Mails ja nicht mehr,
> oder wenn man da einen Drafts-Folder hat, an dem man die Texte editiert,
> bevor sie abgesendet werden.

Bei maildir werden Files nie geändert, soweit ich weiss, sondern neue
gemacht und alte gelöscht (wenn man was `ändert').

> Solange die noch nicht gemailt wurden, sind es ja eigentlich noch
> keine Mails, sondern nur Texte, die mal Mail werden wollen.  Die
> können also prinzipiell auch in einem ganz anderen Format abgelegt
> werden.

Na ja, Texte, die schon ein subject haben und einen Empfänger etc...
Klar kann man die anders speichern, aber bietet sich ja schon irgendwie
an ;)

> > Die Frage ist natürlich, was man machen will.
> 
> Die Frage stellt sich ja immer ;-)

Ja, finde ich auch, hatte nur den Eindruck, dass einige Aussagen hier im
Thread bissel pauschal klangen.

> Endlich mal eins, das den Anforderungen gerecht wird.
> 
> Ich dachte anfangs, es gibt zwei tar-Formate, aber
> es sind fünf oder so.
> POSIX-tar, GNU-tar (aklt), GNU-tar (neu),
> USTAR, ein uraltes V7-tar, und ich glaube da war noch eins,
> oder zwei?

Echt, das ist ein Hammer! Hatte ich blöde Probleme mit automake, weil
das default `make dist' ein Format verwendet, was nur 99 Zeichen lange
PFADnamen kann (!!!! das unter *nix! Hammer!!!). gnutar hatte früher
aber fröhlich längere eingepackt und dabei versehentlich files erzeugt,
die nur noch gnutar lesen konnte, weil standard verletzt. 

Aber es ja immerhin mit gtar funktioniert. 

Das neuere gtar hat das anders gemacht: die Dateien wurden /ausgelassen/
(und ret 0 !!!). Super. Damit funktionierte es nur nicht mehr mit
anderen tars - sondern auch mit gtar nicht mehr. 

Herzlichen Glückwunsch! Das korrekte Verhalten wurde erreicht und ist
portabel (leider für den Preis das das Verhalten `geht nicht' ist, aber
dafür wirklich überall, also portabel).

automake kennt da eine Option, um tar anders aufzurufen, aber auch nur
in ganz neuen Versionen. Da ich mehrere automakes unterstützen muss,
half mir das auch nichts. Mit Tränen in den Augen musste ich ein
tar-wrapper machen, der Optionen reintrixt, damit es in allen Fällen
funktioniert.

Echt prima, so ein automake. Soll man gleich alle Systeme updaten (und
jede Version ist langsamer, als die davor). Da ich das gerade hinter mir
hatte, hab ich das nicht nochmal gemacht, da geht ja auch immer schnell
viel schief.

> Alle haben ihre eigenen Problemchen-.

jaaaaaaaaaaaaaaaaaaaaaaaaa leider

> Da blickt dann keine Sau mehr durch; da es keine Versionskennzeichnung
> in den Files gibt, weiss man auch nicht, was man parsen muss, solange
> bis man merkt, daß das Format nicht stimmt. :(

na ja, bisschen was ist wohl erkennbar, oder?

> Wenn man sich also für eines der Formate entscheidet, bleibt man in
> dem Problemkreis.

Ja, und POSIX ist wohl ausgerechnet dass, was man am seltensten findet,
im tar erst seit kurzem drin ist UND IMMER NOCH LIMITS hat. Ich glaub,
es sind dann 256 Zeichen Pfadname.

> Also ein neues entwerfen, welches die Vorzüge der anderen
> vereinigt, die Nachteile bleiben lässt und ein paar andere
> nützliche Eigenschaften hat.

Genau, und dass ist dann ein weiteres, was die Verwirrung erzeugt. Ich
freu mich z.B. immer, wenn ich .arc, .7z oder .rars kriege - und da
gibts viel Potential lol oder self-extractors, die dann genau unter win
gehen oder so. Auch fein.

> Aber so Sachen, daß ein zu langer Filename die Längenfelder
> überschreibt, die will man sich doch nicht wirklich ans Bein binden,
> oder? Also was neues machen.  Vielleicht sollte man es auch nicht mehr
> "tar" nennen, sonst klebt man noch an dem alten Zeugs, und man wird
> von den tar-Traditionalisten geteert und gefedert. ;-)

Gibt sicherlich vieles, was *diese* Anforderungen erfüllt, vermutlich
auch ein aktuelles tar mit richtigen Optionen.

Aber tar ist der tape archiver. Für Bänder würde Dein Tool vermutlich
nicht mehr gehen :) Also .zip? :)

> > Gibt es sowas eigentlich? Was beispielsweise konfigurierbar
> > Redundanz in Datenströme einfügt oder so?
> 
> rar/par/par2-Format machen das, aber ich weiss nicht, ob das
> konfigurerbar ist mit der extra-redundanz. Ich würde mal vermuten, es
> ist festgelegt.

rar hat Extra-Redundanz? Interessant.

Quickpar (für par2?) http://parchive.sourceforge.net/ klingt interssant,
mal lesen, danke!

oki,

Steffen

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