nicht angemeldet
IIS4 haelt HTML-Dateien zu lange geoeffnet
Tag, Tag!
Ich hab mal wieder meine lieben Sorgen mit dem IIS4, naja, so langsam
gewoehnt man sich ja dran.
Wenn ich meine huebschen Seiten schreibe, so habe ich die Dateien in
meinem Texteditor offen, druecke ab und zu Save und dann in meinem
Browser Reload, um mir meine Fortschritte anzusehen. (Ist ja wohl
nicht ganz unueblich, diese Vorgehensweise *g*.) Nun mache ich
manchmal nur sehr kleine Aenderungen, sodass zwischen zwei Reloads nur
so etwa 10 Sekunden vergehen (sollten). Das Problem ist, dass ich so
kurz, nachdem ich eine Seite vom Webserver abgerufen habe, nicht
gleich wieder vom Texteditor aus speichern kann, da der IIS die vorher
angeforderte Datei offenbar geoeffnet haelt und somit eine sharing
violation auftritt (zu deutsch: Zugriff auf die Datei wird verweigert,
weil sie eben vom IIS noch geoeffnet ist). Und so habe ich also immer
mindestens so ungefaehr eine Minute zu warten, bis der IIS sich mal
bequemt, die Datei wieder freizugeben, damit ich meine Aenderungen
speichern und die Seite erneut aufrufen kann. Naja, und mit der Zeit
nervt das ganz gewaltig.
Bisher hatte ich ASP-Seiten geschrieben, die diverse SSI-Anweisungen
enthielten, und da gab es dieses Problem nicht. Diese hat er immer
sofort wieder freigegeben, deswegen bin ich diesem Problem bis jetzt
noch nicht nachgegangen, obwohl ich bereits davon wusste. Doch jetzt
mache ich wieder stinknormale HTML-Seiten und ein paar Perl-Scripts
dazu, weil das ganze mal auf Solaris mit Apache laufen soll. Und bei
*.html-Files tritt das Problem eben auf.
Meine Frage duerfte zu erahnen sein: Gibt es beim IIS4 irgendwo
irgendeine Einstellung, wodurch dieser "Webserver" (*raeusper*) eine
Datei sofort wieder freigibt? In den 1000 Dialogboxen der Management
Console habe ich nichts vernuenftiges gefunden. Aber manche Variablen
muss man direkt in der MetaBase mit einem VBScript (adsutil.vbs)
setzen (ein Hoch auf Microsoft, da hatten sie mal wieder einen ihrer
Geistesblitze).
Hoffe einer von Euch sicherlich auch leidgeplagten IIS-Nutzern hatte
schon mal so ein Problem (und es geloest).
Calocybe
P.S. Ich hoffe, Stefan gefaellt der Blocksatz, hat er sich ja extra
gewuenscht. ;-)
-
Moin,
Ich hab mal wieder meine lieben Sorgen mit dem IIS4, naja, so langsam
gewoehnt man sich ja dran.komisch, mit IIS Version 2 hab ich ähnliche Probleme, bloß "umgekehrt". Man kann zwar Dateien (cgi Skripte) in Server-Tree speichern, es dauert aber eine endliche Zeit, bis der Server dies auch mitbekommt. Solange scheinen weiterhin die alten cgi's zu existieren. Du kannst ja mal ausprobieren, ob es da im "Fehlverhalten" zwischen .html-Dateien und cgi's einen grundlegenden Unterschied gibt.
.... dieser "Webserver" (*raeusper*) eine
*handschüttel* ;-)
Viele Grüße
Andreas
-
Hi!
komisch, mit IIS Version 2 hab ich ähnliche Probleme, bloß "umgekehrt". Man kann zwar Dateien (cgi Skripte) in Server-Tree speichern, es dauert aber eine endliche Zeit, bis der Server dies auch mitbekommt.
Dieses Problem kenne ich ausserdem noch. Waehrend sich meine Frage auf einen Testserver bezog, der in meiner Naehe steht, hat unser Produktiv-Server stattdessen das Problem, dass er eine geaenderte ASP-Datei manchmal tagelang nicht anerkennt und immer noch die alten Inhalte ausgibt. Ich kann eine Datei sogar loeschen, und er merkt es mehrere Tage nicht! Nach einem Neustart des Webserver-Prozesses rafft er's dann, und dann tritt das Problem auch erst mal ein paar Wochen nicht auf. Aber wenn er dann wieder laengere Zeit gelaufen ist, fangt er wieder mit diesen Macken an.
CGI's funzen aber ganz gut, da hatte ich diesbezueglich noch keine Probleme. Aber ASP ist ja nicht so richtig CGI. Scheinbar werden die ASP-Ergebnisse irgendwie gecachet, aber der Cache funzt nicht so richtig, wie er soll. Browser- oder Proxy-Cache sind definitiv nicht im Spiel.
Doch zurueck zur eigentlichen Frage:
Du kannst ja mal ausprobieren, ob es da im "Fehlverhalten" zwischen .html-Dateien und cgi's einen grundlegenden Unterschied gibt.
CGI's (Perl) sind nicht betroffen, wohl aber HTML und JS. Vermutlich also solche Dateien, die nicht erst irgendwie verarbeitet werden, sondern einfach von der Festplatte reingezogen und an den Browser zurueckgeschickt werden. Ist nicht weiter verwunderlich: Ein Perlscript wird nicht vom Webserver geoeffnet, sondern vom Perl-Interpreter, und der haelt die Datei natuerlich nicht laengere Zeit geoeffnet. Was ASP's angeht, so hatte ich da haufenweise #includes drin. Vielleicht hat er pro Client immer nur eine Datei gleichzeitig offen haben wollen und deshalb die .asp gelesen und wieder geschlossen, bevor er die *.inc eingelesen hat.
Aber es bringt wohl nicht so viel, darueber zu spekulieren, wie MS seinen Webserver programmiert hat.... Zum Glueck kriege ich bald meinen Apache. *freu*
Calocybe
P.S. Hey Patrick, falls Du das liest, kannst Du jetzt ungefaehr verstehen, warum ich Microsoft nicht ausstehen kann?
-
Also ich hab nur probleme mit dem speichern, wenn man die index(default.asp, index.html, je nach einstellung) datei speichern/offnen will. Mit Visual Interdev über die Frontpage erweiterung geht es ohne Probleme.
-
Hi!
Also ich hab nur probleme mit dem speichern, wenn man die index(default.asp, index.html, je nach einstellung) datei speichern/offnen will. Mit Visual Interdev über die Frontpage erweiterung geht es ohne Probleme.
Aeh... Frontpage-Erweiterung? Muss man sowas jetzt benutzen, um in zu sein? Sorry, aber ein Webserver, wo man nicht mal eine Datei speichern kann wegen der von mir beschriebenen Probleme, ist fuer mich kein vernuenftiges Stueck Software. Naja, und eine Erweiterung zu installieren, um den Bug zu umgehen, das ist ja auch nicht der wahre Weg.
Aber morgen kann ich mir zum Glueck ne gute alte Sparc aufstellen, da kommt ein Solaris und ein Apache drauf, und dann hat der staendige Aerger ein Ende, hoffe ich zumindest.
Calocybe
-
-
-