[linux-l] mbox/Maildir/tar

[Oliver Bandel]

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

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

Ist aber nichts, was RFC-mässig gefordert ist.
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.

So gesehen gehen unsere mbox-bezogenen Diskussionen alle am Thema
vorbei. Es geht dann nämlich garnicht um mbox- oder nicht-mbox,
wenn man über Status-in-der-mbox oder status-in-externem-Index redet,
sondern um die Frage, wie man es denn am besten machen will.

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

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

Hätte jeder Leser seinen eigenen Index zu den mboxes,
dann könnte er/sie/es sich die Mails mit anderen Teilen,
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.
Und jeder hat seine eigenen Statusflags.

Damit man im Mail-Dir (beachte den "-" ;-) ich meine nicht Maildir;-))
nicht versehentlich nen Index löscht, kann man ja die allseits bekannten
2."-files nehmen und die Index-Files in einem .mailindex-Dir
unterbringen.



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

Hihi. Meinst Du? ;-)




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

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. so ein Provider wird ja sicherlich auch mal
OpenSourceSoftware einsetzen und vielleicht den einen oder anderen
Programmierer haben, der sowas bauen kann.
So drastisch kann das ja nicht sein (einigermassen lesbare Quellen
voraus gestzt ;-) ...ok, das könnte manchmal schwierig werden ;-))





[...]
> > 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...?!


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

Mag sein.


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

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.

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.

> Super. Damit funktionierte es nur nicht mehr mit
> anderen tars - sondern auch mit gtar nicht mehr.

heheh.


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



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


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

Also, ich habe nach

http://en.wikipedia.org/wiki/Tar_(file_format)


Eine erste version gebaut, die mir für GNU-tar
die Fileinfos ausliest.
Ich dachte mir: "naja, fang einfach mal an mit GNU-Tar.
Wenn Das dann geht, kannste ja immernoch schauen, ob
de noch Lust hast, auch USTAR zu implementieren."

Naja, und das klappte auch mit eigenen Tars.
Wunderbar sogar.
Dann habe ich mir ein altes Backup raus gesucht, auch von GNU-Tar
8alte Linux-Kiste). Und irgendwann ist der Indexer dann abgeka...
und der Grund war, daß es da einen "././@LongLink"-Eintrag gibt,
der in obigem Dokument nicht erwähnt war.

Also habe ich weiter gesucht im Netz.


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.

Dann habe ich lieber in meinen apalogretrieve
ein "GROUP BY" implementiert. :)
Da war die Zeit sinnvoller investiert, fand ich.




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

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




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


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


http://packages.debian.org/search?keywords=7z&searchon=names&suite=stable&section=all



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

Ja, meinst Du?
Ich bezweifle das.

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.

Und dann müsste man also das super-tar, wenn es dies gäbe,
doch wieder patchen oder doch wieder was eigenes bauen,
das heisst: man kommt um das problem nicht herum, sich mit so
viel Historie herum zu plagen... :(




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

Keeene Ahnung ;-)


Gruß,
   Oliver