[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Oliver Bandel wrote on Thu, Nov 29, 2007 at 20:51 +0100:
> Zitat von Steffen Dettmer <steffen at dett.de>:
> > (Na ja, die Felder stehen bei mbox halt im `header' der mail, ist
> > schon mbox-eigen, oder?)
> [...]
> 
> Ist aber nichts, was RFC-mässig gefordert ist.

Wie meinst Du das? mbox ist nicht spezifiziert (schreibt RFC4155
deutlich). Allgemein ist man sich wohl einig, dass `mbox databases
typically contain a linear sequence of electronic mail messages'.

Wenn man das in Frage stellt / anders sieht, sollte man vielleicht nicht
mehr von mbox reden, um Verwirrungen zu vermeiden.

> Und dort steht auch nichts darüber, daß man mbox-files
> nicht mit einem externen Index verwalten können darf.
> Also ist - so gesehen - auch eine indexed mbox immernoch mbox.

Eine indizierte Menge ist keine lineare Sequenz mehr. Die Operationen
sind anders.
http://qmail.org./man/man5/mbox.html schreibt deutlich
  `A reader scans through an mbox file looking for From_ lines.'
da nützt einem ein Index nichts, weil man ihn nicht benutzen `darf'.

Varianten wie z.B. mboxcl werden genannt und heissen halt anders.

> Nur, weil die meisten mailreader es so machen, wie wir es hier
> diskutieren, muss das ja noch lange nicht sinnvol sein.

Richtig, allerdings steckt da auch sehr viel jahrelange Erfahrung drin.

> Für mich ist jedenfalls nicht das naheliegendste, die Status-Flags
> n den mbox-File zu bringen.
> Spätestens, wenn mehrere User die selben Mails lesen können wollen,
> kommt man damit schon in Bedrängnis. Dann müsste für jeden beteiligten
> User ein eigenes Status-Flag in den header. 

Ja, und wenn man die auf CD brennen möchte, muss man im Header die zu
verwendende Hintergrundmusik vermerken. Von der IP Adresse der
Kaffeemaschine ganz zu schweigen.

Aber dafür ist mbox auch gar nicht da.

> Das ist IMHO reichlich unsinnig. Davon abgesehen ist es eigentlich
> eine Änderung des Dokumentes und eine Änderung eines Dokumentes, nur
> weil man es gelesen hat ist mir nicht ganz einsichtig.

Das ist Abstraktion. Meiner Meinung nach ist es nicht `komisch', einen
*Disk*schreibzugriff zu machen, wenn man eine *Datei* liest. Sind
verschiedene Sachen, auch wenn das heute oft vergessen wird. Auch hier
geht es um zwei Dokumente: das eine ist der Mail*text*. Der hat
Meta-Infos wie Sender und Empfänger - und halt Flags. Die werden in
einem Container (mbox) gespeichert. Ein Meta-Info ist, ob es gelesen ist
oder nicht. Natürlich muss das beim Lesen des Mail*text*s aktualisiert
werden.

> Hätte jeder Leser seinen eigenen Index zu den mboxes,
> dann könnte er/sie/es sich die Mails mit anderen Teilen,

Das geht nicht, weil keiner alle Indices aktualisieren können kann, aber
müsste, wenn er was ändern wollen würde.

> man hätte bei "Mail an Alle" niche eine Mail, die
> mehreehundert oder mehreretausend mal verteilt wird
> und überall doppelt liegt, sondern man hat ein Exemplar
> und alle, die sie lesen wollen, greifen drauf zu.

Da nimmt man in der Praxis meist eine URL.

> > Hat natürlich auch Nachteile bei bestimmten Operationen, Backup usw.
> [...]
> 
> Es spricht ja nichts dagegen, das IMAP aufzubohren und sowas wie ein
> DUMP-Kommando einzubauen, damit der Server seine Daten für's Backup
> heraus gibt. 

Doch, und zwei Sachen fallen mir sofort ein: KISS und Orthogonalität.

> > > 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 ;)
> 
> Wenn man deswegen seine ganze Software aufwändig(er) gestalten muss,
> nur weil man vereinheitlichung am falschen Ort durchsetzen will...?!

Wieso aufwändig? mbox ist doch gerade /einfach/. maildir ist vermutlich
noch einfacher. Da liegt doch gerade die Eleganz. Das geht mit ein paar
Zeilen Code, kann man sogar mit'm Shellscript nutzen. Ein effizientes
cyrus-Format oder so kriegt man vermutlich nicht so schnell in sh hin.
Dann braucht man noch reparaturtools und alles mögliche...

> > 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!!!).
> 
> Ja, in der Tat, das ist schon krass, was?!
> 
> Aber beim CD-/DVD-brennen, Joiletfilesystem, da sind
> es 64 zeichen Basename als maximum, und der Pfad darf nicht länger als
> 120 zeichen sein.

Kein Problem, macht man halt ein tar und brennt das! Dann kommt man
schon bis 256 Zeichen lol
Nee, da kann man ein tar-Format nehmen, was diese Beschränkungen nicht
hat. Oder hat eben unter Joilet andere Filenamen als unter rr oder
kümmert sich einfach nicht um die Beschränkungen (dann geht Win95 eben
nicht mehr).

> Manchmal habe ich schon ewig lange gebaraucht um was zu brennen, nur
> weil ich etwas zu lange Pfadnamen hatte. :(

?

> Habe mir dann ein Script gebaut, das die Pfadnamen-Länge checkt.
> 
> Eigentlich trurig, daß sowas notwendig ist.
> Aber was solls.
> 
> 
> [...]
> > Das neuere gtar hat das anders gemacht: die Dateien wurden
> > /ausgelassen/
> > (und ret 0 !!!).
> 
> Ja, silently discarded.
> Nicht die nette Art, finde ich.
> Wenigstns eine Message nach stderr oder ein "hat-nicht-geklappt.log"
> wäre da sinnvoll.

Es konnte seine Aufgabe nicht erfüllen. Eine Fehlermeldung und Rückgabe
eines Fehlercodes erscheinen mir offensichtlich als das einzig Richtige.

> > 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).
> 
> "Portables geht-nicht", hahah, ja, sollte man sich merken, den
> Ausdruck! :)

ja lol stimmt

> > 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.
> 
> Oh jeh.
> 
> Und kann man das dann hinterher auch ohne Wrapper wieder auspacken?
> Sonst hast Du das Problem nur verschoben ;-)

Ja, der wrapper schmeist nur die tar Option "o" (--old-archive,
--portability: write a V7 format archive, rather than ANSI format) weg,
was automake benutzt (tar chopf glaub ich, bin mir aber nicht sicher).

> Nachdem ich dann
>    http://www.it.cas.cz/manual/tar/html_node/tar_117.html#SEC112
> überflogen hatte, oder schon wöährend dessen,
> hat es mir doch etwas die Laune versaut.

Ja, fetzt "Subsequent changes in POSIX have allocated the same parts of
the header record for other purposes. As a result, GNU tar is
incompatible with the current POSIX spec, and with tar programs that
follow it.". 

> So genau festgelegt ist das wohl auch nicht, auch der POSIX-tar scheint
> nicht so 100% sauber zu sein. Müsste ich nochmal im tar-book nachlesen.
> Link ist ja da oben. Falls Du mal zu guter Dinge bist und zu viel von
> Linux / Unix schwärmst, dann lies den Abschnitt ;-)

Na ja, danke, reicht erstmal :(

> > > 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.
> 
> Nein, nicht wenn man es dann anders nennt.
> 
> Dann heisst es eben nicht mehr tar, sondern "tartar" ;-)
> Oder vielleicht besser "schnulli100" oder so. ;-)

oder rar, arc, zip oder so? :)

> > 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.
> 
> 7z kannste unter Linux auch entpacken.

Ja, die self-extractoren kann man meist auspacken, wenn man den Packer
dazu hat. Aber wenn Du bilder.exe per Mail kriegst? :)

> > Gibt sicherlich vieles, was *diese* Anforderungen erfüllt, vermutlich
> > auch ein aktuelles tar mit richtigen Optionen.
> 
> Ja, meinst Du?
> Ich bezweifle das.

Dein Zweifel nützt Dir aber nix, iss so :)

http://www.gnu.org/software/tar/manual/tar.html#SEC124

posix

    Archive format defined by POSIX.1-2001 specification. This is the
most flexible and feature-rich format. It does not impose any
restrictions on file sizes or file name lengths. This format is quite
recent, so not all tar implementations are able to handle it properly.
However, this format is designed in such a way that any tar
implementation able to read \x{2018}ustar\x{2019} archives will be able
to read most \x{2018}posix\x{2019} archives as well, with the only
exception that any additional information (such as long file names etc.)
will in such case be extracted as plain text files along with the files
it refers to.

    This archive format will be the default format for future versions
of GNU tar.


:-)


Na ja, besser spät als nie.

> Und wenn es das kann, kann es -- für Leute, die nicht auf Band
> sichern, sondern auf Platte oder DVD -- denn auch einen Index
> erstellen und mit so einem einen Direktzugriff ermöglichen?
> 
> Darum ging es mir ja.

Gibt es denn einen Grund, etwas anderes anzunehmen? Ich würde erwarten,
dass es wie vorher auch funktioniert?

oki,

Steffen

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