nicht angemeldet
Hi Christoph,
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.
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?
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.
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.
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.
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).
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.
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 ... ;-)
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael