nicht angemeldet
Hallo Christoph,
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 wie lange dauert es zwischen zwei Prozeß-Instanzen
mit derselben PID? Länger, als das Gzippen einer Datei
dauert. Die übrig bleibende Cache-Datei tut nicht weh
- die wird beim nächsten Mal einfach überschrieben.
Es dürfen nur nicht _gleichzeitig_ zwei Prozesse mit
derselben PID laufen, weil die in dieselbe Datei
schreiben und ein korruptes Ergebnis erzeugen würden.
Die zlib erzeugt übrigens eine Checksum. Warum die
nicht nehmen?
Weil ich dann zuerst im Speicher komprimieren und
danach in die Datei schreiben müßte. Ich müßte also
die Daten lokal auch noch einmal puffern - und dazu
im schlimmsten Fall mit backticks die Ausgabe von
/bin/gzip -c auffangen, grusel ...
Ich hatte eher den Umstand im Auge, das evt
derselbe Datei_name_ mehrfach in den Cache
geschickt wird ;-)
Ich auch (falls derselbe Dateiname über ent-
sprechende 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.
Wie soll das gehen? Innerhalb eines Dateisystems, das
ich kenne, erscheint mir das unmöglich.
Ich kenne mich allerdings in den Pfadtranslations-
mechanismen des Apachen nicht gut genug aus.
Die Dokumentationen zu gzip_cnc und mod_gzip sind
beide zweisprachig und werden via Content Negotiation
über mehrdeutige URLs angesprochen - das ist wohl das
Szenario, welches Du meinst: Mehrdeutige Request-URLs.
gzip_cnc 1.04 wurde damit noch nicht fertig (und
gzip_cncc 0.2 meines Wissens auch nicht). gzip_cnc
1.05 dagegen macht das richtig (ich brauche es ja
für meine eigenen Seiten).
Es funktioniert so:
PATH_INFO ist der angeforderte URL _vor_ Negotiation;
PATH_TRANSLATION ist der vom Apache übersetzte Datei-
name _nach_ Negotiation. Dort sind beispielsweise auch
Directory-Zugriffe schon nach "index.html" etc über-
setzt - gzip_cnc bekommt immer einen eindeutigen
Dateinamen, allerdings nur in PATH_TRANSLATED, nicht
in PATH_INFO.
gzip_cnc 1.04 nahm noch komplett PATH_INFO und adres-
sierte dann in der Tat fälschlicherweise sämtliche
negotiated-Varianten eines URL über dieselbe Cache-
Datei, lieferte also zufällige und unbrauchbare Sprach-
Varianten aus (der erste Zugriff erzeugt die Cache-
Version, alle nachfolgenden Zugriffe glauben ihren
Inhalt).
gzip_cnc 1.05 nimmt, um nun den Pfadnamen der zuge-
hörigen Cache-Datei zu berechnen,
a) den Verzeichnispfad aus PATH_INFO, aber
b) den Dateinamen aus PATH_TRANSLATED.
Nun entstehen für index.htm.de und index.htm.en zwei
verschiedene Cache-Dateien, die beide für den URL
index.htm ausgeliefert werden könnten.
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*
;-)
Wie meinen der Herr?
PS: sind meine Mails angekommen?
Äh ... hier privat nicht.
(Ins Büro komme ich erst wieder nach dem Halbfinale.)
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael