nicht angemeldet
Hallo,
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.
Ja, das fiel mir auch auf, just als ich das "Danke" vom Forum erhalten hatte ;-)
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.
Wenn gleichzeitig zwei Prozesse mit derselben PID laufen, hast Du andere Probleme als ein korruptes Ergebnis ;-)
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 ...
Ach hör doch auf! Als, ob Dir vor sowas gruseln würde! ;-)))
Aber ich habe mir die C-Portierung vorgenommen, und da die Sache einmal durchgespielt. Nützt auch nichts.
Um vom getpid() wegzukommen kann man nur reguläres Filelocking betreiben.
Das ist Aufwand in zweifacher Hinsicht: einmal die Implementierung selber und zum anderem der Overhead bei der Ausführung.
Nein, um getpid() ist leider nicht einfach genug herumzukommen.
Reines ANSI-C ist demnach zu aufwendig. (Was mich ein wenig wurmt) aber zumindest der POSIX Standard läßt sich einhalten, wenn man ihn nicht voll ausnutzt.
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.
Nein, nicht im Dateisystem ;-)
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.
Ja, genau. Danke.
Irgendwas war da doch ncoh, soviel wußte ich noch ;-)
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.
Hat er auch geändert. Zumindest steht bei mir getenv("PATH_TRANSLATED")
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.
Nein, das tut gzip_cncc noch nicht.
Betonung liegt auf _noch_ nicht ;-)
(In der stillen Hoffnung, daß ich das jetzt auch richtig verstanden habe)
Wer baut eigentlich PATH_INFO zusammen?
Verdammt, ich muß mir doch mal ein vernünftiges cgi-bin zusammenschustern ;-)
(So ganz ohne ist das irgendwie schlecht mit Testen, geht zwar auch, aber ... ;-)
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?
Nichts, nichts, Herr Kollege. ;-)
Du warst eh nicht gemeint. Habe nur mal meinem Unmut etwas Luft gemacht.
Wollte mir einige Teile einer Dokumentation runterladen und mußte feststellen, das die anstatt über verschiedene Dateinamen und einer anständigen Verzeichnisstruktur, statt der verschiedenen Dateinamen verschiedene Verzeichnisse genommen hatten und überall war eine Datei drin: index.htm.
Wenn man dann aus dem Inhaltsverzeichnis ein paar der Links hinter ein wget packt und dann nicht drauf achtet ...
Ja, ich weiß, C&P hat schon so manches Opfer gefordert ;-)
PS: sind meine Mails angekommen?
Äh ... hier privat nicht.
Ja, was man macht, macht man verkehrt *sigh* ;-)
(Ins Büro komme ich erst wieder nach dem Halbfinale.)
Was für ein Halbfinale?
so short
Christoph Zurnieden