[quote=sid burn,11.07.2007, 14:19]Sind aber nur Advisorys. Sprich daran muss sich keiner halten. Aber das ist ja flock() auf Linux Generell. Glaube nur die BSD Systeme verfügen über einen Exclusiven Lock.[/quote]
Linux hat auch Mandatory Locks. Siehe "Mandatory Locking" in fcntl(2). Ich finde allerdings nicht, dass man so etwas jedem Benutzer (bzw auf jedem Dateisystem) erlauben sollte, denn damit kann man z. B. cronjobs wie updatedb ziemlich aergern.

Edit: Naja, das mit updatedb stimmt nicht, denn der liest ja keine Dateien aus.\n\n

<!--EDIT|betterworld|1184177558-->

<iro>http://board.perl-community.de/cgi-bin....0;t=779</iro>

:D\n\n

<!--EDIT|opi|1184180869-->

flock kannst du wohl nicht verwenden, weil der lock automatisch wieder aufgehoben wird (bzw. aufgehoben werden sollte, wenn das programm beendet wird. und das ist ja bei CGI-Programmen dauernd der fall

Hallo Strat,

ja, mit einem CGI-Skript, welches sich sofort beendet, klappt das natürlich
nicht. Ich wollte konkret auf die Frage des Threaderstellers eingehen:

Quote

Also, meine Frage ist nun: Geht das auch mit Hilfe von flock()??

Auf irgendeine Weise ist das mit sehr viel Phantasie und sehr viel AJAX etc.
eventuell möglich, allerdings abwegig. Vielleicht habe ich die Frage einfach
zu ernst genommen. =)

Viele Grüße,
opi

[quote=sid burn,11.07.2007, 14:19]File Locks stehen übrigens in: /proc/locks

Sind aber nur Advisorys. Sprich daran muss sich keiner halten. Aber das ist ja flock() auf Linux Generell. Glaube nur die BSD Systeme verfügen über einen Exclusiven Lock.[/quote]
*BSD nicht, jedenfalls finde ich nichts in der Manpage, aber dafür wahrscheinlich Windows.

ihr seid echte FREAKS^^
aber wie singen die beatsteaks so schön "hail to the freaks" :)


danke für alle Ideen
@nepos danke für die Erinnerung das Schreiben ins logfile durch flog() zu sichern, das habe ich glatt vergessen

Ich hätte ja noch einen etwas ausgefallenen Lösungsvorschlag, der nicht mit Lockfiles, sondern flock arbeitet, trotzdem mit CGIs funktioniert und ein paar Vorzüge hat:

* Teile das Problem in zwei Programme, einen Fileserver und ein CGI.

* Der Fileserver wird als permanenter Serverprozess neben dem Webserver gestartet. Er öffnet einen Unix-Domainsocket und beginnt darauf zu lauschen.

* Das CGI-Programm sendet, anstatt eine Datei selbst zu öffnen, über den Domainsocket eine Anfrage an den Fileserver. Die Anfrage enthält die Information, welche Datei geöffnet werden soll und ob Lese- und / oder Schreibzugriff verlangt wird.

* Der Fileserver erhält die Anfrage, öffnet die Datei mit dem entsprechenden Modus und besorgt sich die nötigen Locks. Wenn eine dieser Operationen fehlschlägt, antwortet er dem CGI-Programm mit einer aussagekräftigen Fehlernachricht. Wenn die Datei erfolgreich geöffnet wurde, merkt sich der Fileserver den Dateideskriptor mit seiner Erstellungszeit in einer internen Liste und schickt ihn dann über den Domainsocket an das CGI-Programm.

* Das CGI-Programm erhält den Dateideskriptor oder die Fehlermeldung als Antwort auf seine Anfrage.

* Das CGI-Programm tut, was es tun soll, oder auch nicht ;-)

* Das CGI-Programm beendet seine Arbeit und schickt dem Fileserver eine Anfrage, den gegebenen Dateideskriptor freizugeben.

* Der Fileserver erhält die Anfrage, schlägt den Deskriptor in seiner internen Tabelle nach, entfernt ihn dort, gibt die Sperren frei und schließt den Deskriptor.

* Parallel durchläuft der Fileserver in vorgegebenen Intervallen die Liste der Deskriptoren und gibt diejenigen wie im letzten Schritt frei, die bereits zu alt sind.

Dieser Ansatz sieht komplizierter aus, als er tatsächlich ist, lässt sich hervorragend in einen Server und eine Bibliothek kapseln, so dass er vom CGI-Programmierer weniger wahrgenommen wird, als die anderen Ansätze und hat den zusätzlichen Vorteil, dass das CGI mit minimalen Privilegien gestartet werden kann, so dass es lediglich über den Fileserver auf lokale Dateien zugreifen kann; der Fileserver aber kann eine Zugriffskontrolle für die Dateien implementieren und die Zugriffe loggen, was die Sicherheit und Kontrollierbarkeit des Gesamtsystemes verbessert.

waaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhh,

nur nochmal zur Info, ich bin ein Neuling in Perl ;)

zu deiner Idee:
1. Fileserver..... sorry aber da hörts bei mir auf, habe ich noch nie einen angelegt genutzt oder dergleichen

2. ein zusätzlichen Server laufen lassen?! für eine kleine Datei, scheint mir etwas übertrieben

3. ich verstehe zwar deine Idee, aber ehrlich gesagt wirft es bei mir nur Fragen auf was die Realisierung angeht, ich wette da bräuchte ich ewig viel Zeit die ich leider nicht habe

aber Respekt, darauf muss man erstmal kommen^^

@murphy
Hört sich gut an, ich denke aber so einen Server zu Implementieren, der dann auch Sicher ist, ist auch nicht gerade so einfach.

Ansonsten Funktioniert diese Möglichkeit aber auch nur, wenn der Server einem selber gehört. Auf Webhosting etc. wird man das nicht realisieren können. Dort haben die Prozesse meist eine maximale Laufzeit für die User, um Programme mit endlosschleifen etc. zu vermeiden.

Kommt wohl immer auf das Drumrum an. Wenns nix großes ist und man vielleicht auch nur bei einem Webhoster das ganze am Laufen haben will, dann ist der Fileserver sicherlich überzogen bzw. gar nicht möglich.

Ich denke, der Vorschlag, eigene Lockfiles zu verwalten dürfte relativ einfach zu realisieren und für die Anwendung ausreichend sein.