[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Oliver Bandel wrote on Sat, Dec 01, 2007 at 12:19 +0100:
> > > Ja, sozusagen ein Hash :)
> > > Filename ist der Key und Inhalt ist die Value.
> >
> > Muss gar kein Hash sein, weil man vom Inhalt gar nicht zum Key kommen
> > können muss. Kann man eine Zufallszahl oder einen Zähler nehmen oder
> > so.
> 
> Wieso muss man beim Hash vom Inhalt zum Key kommen?
> Wenn man Hash perlish benutzt, was ich tat, womit ich wohl
> informatik-mäßig falsch gesprochen habe, weil ich das
> reserved Keyword "Hash" falsch benutzte, dann habe
> ich damit ein assoziatives Array gemeint.
> Dann meinte ich nich teine Funktion, die wie bei md5sum aus einem
> Inhalt auf einen Key schliesst.

Na ja, es ist kein MD5 Hash sondern ein anderer (schnellerer, aber
u.U. leichter rückwärts-rechenbarer) Hash Algoritmus.

Bei einem assoziativen Array würde man ja sowas machen wollen:

  $mail = "From me\nTo: you\nSubject: x\n\nno body";
  %mails{$mail} = $mail;

das meintest Du doch, oder? Das funktioniert. Im hash mails wird unter
dem hash von $mail (vielleicht ist es 60a8c22e oder was auch immer) die
Mail gespeichert. Wenn mail sehr kurz ist, kann man schnell Einträge
finden (man muss nicht suchen, sondern nur hashen). Hier hätte man ja
aber den gesammten Inhalt zu hashen, was teuer klingt. Da man das aber
gar nicht braucht, würde ich hier eher keinen Hash (assoziatives Array)
nehmen, sondern eher ein normales array / eine liste:

  $mail =...
  push @mails, $mail;

(gut, ich würde ne Referenz pushen, aber dann würde man oben auch eine
Referenz speichern oder gar als key nehmen. Ne Referenz als Key ist aber
ziemlich genau eine Zufallszahl).

> Wie der Key intern verwaltet wird, ist mir egal. Das wird mir
> weg abstrahiert. Ich gebe einen Namen als Key und sage
> was die Value ist. In Perl nennt man sowas Hash.

ja, genau. Vielleicht hab ich mich unklar ausgedrückt, auf jeden Fall
ungenau (wie auch `im hash speichern' ja ungenau ist). Ich meinte mit
key den (unsichtbaren) echten Schlüssel (also den Hashwert). Der
sichtbare Key (den man in Perl auch so nennt, den unsichtbare würde man
vielleicth `hashwert' nennen) ist gleich dem Inhalt (%mails{$mail} =
$mail;). Richtig hätte ich sagen müssen: da man eine Mail nicht nach
ihrem Inhalt suchen können muss, nützt einem die Verwaltung als Hash
hier nicht viel.

> Also benutzt Perl an auch eine Sprache, die einem Informatiker
> nicht gerecht wird?

na ja, man kürzt halt gern ab. Meistens ist das ja auch fein, weil `im
Hash speichern' ja klar genug ist. Gut, mathematisch natürlich Quatsch,
weil ein Hash eigentlich eine Funktion ist, die eine Zahl erzeugt, in
die man natürlich nichts speichern kann. Aber wenn es um was speichern
geht, denkt man ja bei Hash automatisch an eine Hash*tabelle*. Dachten
wir beide ja auch, also hat die Sprache funktioniert, auch wenn es
strenggenommen falsch war :)

> Welches Keyword hat denn hier Vorrang?
> Gibt's da nen Standard, oder zählt, was üblich ist?
> Dann wäre
>  perlish die richtige Variante und wer "Hash" als Funktion
> zur Schlüsselgenerierung meint, liegt damit falsch.

perlish ist schon genau das gleiche, nur dass man `hash' als Kurzform
für `associative arrays of scalars' verwendet, wohl wissend, dass dabei
ein Hashtabelle zum speichern genutzt wird. Das ist ja auch ein
essentielles Feature. Man könnte assoziative Arrays auch als einfach
verkettete Liste implementieren. Das könnte man z.B. für vorn oder auch
hinten anhängen optimieren, aber der direkte Zugriff wäre langsam
(unmöglich), weil man sich immer die Liste langhangeln müsste. Bei einem
hash ist einfügen (u.U.) teuer, die Zeit nicht genau bestimmbar (hängt
z.B. von Kollisionen ab etc), nicht für alle Daten geeignet (obwohl
Ausnahmen eher theoretisch sind) und der Zugriff auf einelementige
Hashtabellen (mit langen Schlüssel) ist viel langsamer als auf sehr
kurze Listen (aber schnell weil klein, also egal).

Das alles kann man schön abkürzen, wenn man einfach `im hash speichern'
sagt :)

> Genauso benutzt man auch einen Dir-Entry: man hat nen Key und eine
> Value. Key ist der Filename, Value der Inhalt des Files.

Genau, nur das man hier ja keinen Key hat (der Filename ist ja `egal').
Also muss man sich einen ausdenken, genau. Bei Hashes könnte man dazu
dann ja den Inhalt nehmen, der ist eindeutig und was anderes hat man
gerade nicht. Würde auch bei Dateien gehen, wenn man den Inhalt der
Datei als Dateinamen nimmt oder den Hash des Inhaltes, damit er kurz und
Sonderzeichen frei bleibt. Oder eine Zufallzahl. Die kann ja ruhig
vorhersagbar sein, also kann man timestamp (concat) PID (concat)
hostname (concat) Zähler oder sowas nehmen.

Das wäre auch ein besserer hash key, denke ich, weil viele solcher
Schlüssel schnell und billig erzeugt werden können.

> [...]
> > > Und da man auch keinen anderen Lesen lässt,
> > > dann verstellt sich auch die atime nicht.
> >
> > Doch, die atime ändert sich ja gerade. Es wird ein neues tmp file
> > angelegt (neue atime). Dann das alte File kopiert (auch neue atime,
> > aber
> > egal), dann neues file in altes umbenannt. Man hat neue atime (und
> > ctime
> > und mtime).
> 
> häh?

sorry, ist etwas knapp, die Frage :)
Wenn man einfach in einer mbox eine Datei löscht, muss man neues File
machen, bis vor zu löschende Datei schreiben, zu löschende Datei
überspringen, Rest schreiben, tmp file umbennen. Danach hat die (neue)
mbox Datei neue a,c,mtimes.

> > > Das ganze $HOME wegmetzeln....
> >
> > (guckst Du zuviel Fernsehen??? :))
> 
> Nicht mehr so oft, aber vielleicht sind das die spätfolgen
> aus meiner Kindheit ;-)

Ahh, ok. Sonst hätte ich das Moorhuhn im Verdacht gehabt.

oki,

Steffen

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