gzip_cnc

[Christoph Zurnieden]

Hallo,

Es wird aber sowieso umbenannt. Der endgültige Name
folgt einer bekannten Gesetzgebung (sonst könnte er
ja nicht gefunden werde, gelle? ;-).
Warum also wird überhaupt ein derart streng
definierter Identifikator gesucht?

weil das Erzeugen des komprimierten Inhalts signifikant
länger dauert als das Umbenennen des Ergebnisses.
Die Wahrscheinlichkeit für eine Kollision beim Kompri-
mieren ist viel höher als diejenige beim Umbenennen -
und die letztere soll gefälligst das Betriebssystem
behandeln.

Da gecachet wird, käme das aber nur beim ersten Mal vor.
Aber gut, das ist auch ein Argument, das erste Mal etwas komplizierter zu gestalten, da es ja eh nur einmal vorkommt ;-)

Auf EEXIST muß sowieso geprüft werden, da auch eine
PID im Laufe eines Serverlebens mehrfach (halt nur
nie gleichzeitig) auftauchen kann.

Kann sie - wirklich?

Ja.
Da ein rename() Fehler nicht abgefangen wird, kann die Datei weiterexistieren.
Wenn die PID Zählung am Ende angekommen ist, wird wieder am Anfang begonnen (nicht ganz und nur unter den mir bekannten Unices, aber das ist der Großteil der Server Betriebsysteme)
Das kann bei Großbetrieben durchaus häufiger auftauchen.

Aber ich gebe es zu: ist ein relativ schwaches Argument, wollte ja eigentlichg nur von getpid() weg ;-)

Die zlib erzeugt übrigens eine Checksum. Warum die nicht nehmen?
Nein, hast recht, würde die Sache unnötig verkomplizieren.

Mir ist immer noch nicht ganz eingängig, warum beim
Tempfile ein _ein_deutiger Identifikator da sein
muß.
Besser wäre es doch, in einem Temdir die Dateien mit
richtigem und vollständigem Namen abzulegen, sodaß
ein EEXIST die Mehrfachüberschreibung im Keime
erstickt.

Ich traue dem EEXIST nicht.
Ich traue überhaupt keinem trivialen Mechanismus zur
Synchronisation. Ein

if (! EEXIST)
      { create zipped file }

kann genau in dem Moment platzen, wenn nach dem "if"
ein Prozeßwechsel statt findet und der andere gzip-
Prozeß ebenfalls in die kritische Zone hinein läuft.

Das ist unwahrscheinlich, da diese Stelle linear ist.
Aber auch hier zugegeben: nur unwahrscheinlich, nicht unmöglich.

Da ist meine Hoffnung, daß dasselbe Problem innerhalb
des Betriebsystemkommandos für die Umbenennung einer
Datei zuverlässiger gelöst ist, als ich das könnte,
doch erheblich.

Gut, Dateisystembearbeitung wird im Normalfall in einem Rutsch abgearbeitet.
Zumindest in den mir bekannten Dateisystemen und Kerneln ;-)

Also komprimiert immer nur der erste gzip_cncc
Prozess die Datei und belastet den Prozessor und
das Dateisystem. Der Rest arbeitet ganz normal.

Der Fall der Kollision ist so selten, daß er in Sachen
CPU-Belastung irrelevant ist.
In Sachen Datenkonsistenz ist er es nicht, da die kom-
primierte Datei anschließend beliebig oft gelesen wer-
den könnte.

Da haut dann der Teil rein, daß Du unbedingt globale Indentifier haben wolltest. Wenn stattdessen die Identifier zur Datei gehörig wären, könnte man tatsächlich auf EEXIST gehen.
Aber bis jetzt ist Eure Version immer noch die einfachste.

Denke ich wirklich so kompliziert?
Scheint wohl so ;-)

Ich hatte eher den Umstand im Auge, das evt derselbe
Datei_name_ mehrfach in den Cache geschickt wird ;-)

Ich auch (falls derselbe Dateiname über entsprechende
Alias-Mappings auf mehrer URLs abgebildet wird, haben
wir halt ein bißchen Redundanz im Cache).

Ich meinte den umgekehrten Fall. Das also mehrere Dateien den gleichen Namen haben könnten. Ich kenne mich allerdings in den Pfadtranslationsmechanismen des Apachen nicht gut genug aus.
Die von Dir angesprocchen Redundanz ließe sich übrigens mit dem ZLib Checksum Mechanismus (ist zwar nur 32 Bit, aber das reicht ja in diesem Falle) vermeiden.
Aber ob sich der Aufwand lohnt?

Und ich wollte _eine_ Wurzel des Cache-Baums haben,
ohne dafür die Wurzel des gesamten Verzeichnisbaums zu
verwenden ... das wäre auch gegangen, hätte aber
längere Pfadnamen zur Folge gehabt.
Hätte auch keine große Rolle gespielt.

Es geht mir hier auch um die usability.
Ich selbst habe beim Testen immer wieder in den Cache
geschaut, um zu prüfen, ob alles so tut, wie es sollte.
Das wird den Benutzern, die gzip_cnc installieren,
möglicherweise ähnlich gehen - und in diesem Falle ist
ein "kurzer" Pfadname angenehm.

Ja, insbesondere für die Leute, die einem das automatisierte Runterladen schwer machen, in dem sie jede "Wurzeldatei" in jedem Unterverzeichnis als "index.html" bezeichnen.
*grrr*
;-)

die Trivial-Methode, nur fertige Dateien durch Umbe-
nennung um Cache "sichtbar" für andere Zugriffe zu
machen.
Na, _so_ trivial ist sie ja auch nicht ,-)

"rename" hat sich bei ähnlichen Fällen bewährt - ich
mache das seit vielen Jahren so. (Deshalb weiß ich
auch gar nicht, wie "flock" funktioniert ... ;-)

flock() ist ja auch immer so eine Sache und eh nicht ANSI ;-)
Bevor Du nachschaust: rename() ist:

C99: 7.19.4.2 The rename function
[...]
Among the reasons the implementation may cause the rename function to fail are that the file is open or that it is necessary to copy its contents to effectuate its renaming.

Oh!
Kommt davon, wenn man nicht nachschaut ,-)

Wollen hoffen das sich die jeweiligen Libc Implementationen auch an den Standard halten ;-)

so short

Christoph Zurnieden

PS: sind meine Mails angekommen?