Es gibt massenhaft Anleitungen, wie ich eine Datei mit
flock() schütze. Ich habe aber nichts darüber gefunden,
was passiert, wenn ich eine gelockte Datei öffnen will.
Wird dann bei "open || die" das Programm abgebrochen?
Oder wartet "open" stillschweigend, bis die Datei wieder
zugänglich ist?
Paul Lenz
Paul Lenz schrieb:
> Es gibt massenhaft Anleitungen, wie ich eine Datei mit
> flock() schütze. Ich habe aber nichts darüber gefunden,
> was passiert, wenn ich eine gelockte Datei öffnen will.
> Wird dann bei "open || die" das Programm abgebrochen?
> Oder wartet "open" stillschweigend, bis die Datei wieder
> zugänglich ist?
Probiere es doch einfach aus!
Generell ist es so, dass flock nur vor flock schützt. Wenn jemand flock
nicht benutzt, schützt es nicht.
Doku: perldoc -f flock
``This means that programs that do not also use "flock" may modify files
locked with "flock".''
Wolf
Paul Lenz wrote:
> Es gibt massenhaft Anleitungen, wie ich eine Datei mit
> flock() schütze. Ich habe aber nichts darüber gefunden,
> was passiert, wenn ich eine gelockte Datei öffnen will.
> Wird dann bei "open || die" das Programm abgebrochen?
> Oder wartet "open" stillschweigend, bis die Datei wieder
> zugänglich ist?
Beim open() passiert nichts. Erst der flock()-Aufruf
hängt (bzw. zeigt Fehler an, wenn non-blocking),
bis die Datei freigegeben wird.
Aber wie mein Vorposter schon sagte: Probiers aus!
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Paul Lenz:
> Es gibt massenhaft Anleitungen, wie ich eine Datei mit
> flock() schütze. Ich habe aber nichts darüber gefunden,
> was passiert, wenn ich eine gelockte Datei öffnen will.
> Wird dann bei "open || die" das Programm abgebrochen?
> Oder wartet "open" stillschweigend, bis die Datei wieder
> zugänglich ist?
Die meisten Betriebssysteme implementieren flock() (den
Systemcall) als "advisory locking", d.h., es wird erwartet,
dass alle Prozesse, die auf eine gemeinsam genutzte Datei
zugreifen wollen, vor dem open() ein flock() absetzen und
damit prüfen, ob ein Zugriff möglich ist. Tun sie das
nicht, sondern verwenden open() sofort, hindert sie das
Betriebssystem daran nicht - mit allen sich möglicherweise
daraus ergebenden Folgen.
Ich weiß nur von einigen wenigen OS (AIX, VMS), die ein
"mandatory locking" implementieren, d.h, wo open() einen
Fehler zurückliefert, wenn eine mit gelockte Datei durch
einen anderen Prozes geöffnet werden soll.
Deine Frage hat also mit Perl eigentlich nichts zu tun,
sondern es geht darum, welche Lockingart dein Betriebs-
system implementiert. Da du nicht dazugeschrieben hast,
um welches OS es sich handelt, kann man weiter nichts
dazu sagen. Windows und Linux jedenfalls hindern dich
nicht daran, eine mit flock() gelockte Datei mit open()
zu öffnen (d.h., sie implementieren "advisory locking").
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Ferry Bolhar
> Die meisten Betriebssysteme implementieren flock() (den Systemcall)
> als "advisory locking", d.h., es wird erwartet, dass alle Prozesse,
> die auf eine gemeinsam genutzte Datei zugreifen wollen, vor dem
> open() ein flock() absetzen und damit prüfen, ob ein Zugriff möglich
> ist.
Nein, denn das geht nicht. flock() arbeitet mit einem Filehandle, d.h.
du *musst* die Datei zunächst per open() öffnen und kannst erst dann
das flock() aufrufen. Natürlich sollte man die zu "schützenden"
Filehandle-Zugriffe erst nach einem erfolgreichen flock() machen, nicht
schon zwischen open() und flock().
Und wenn man die Datei im Append-Mode öffnet, schadet ein seek(FOO, 0,
2) - wie von der Perl-flock-Dokumentation vorgeschlagen - direkt nach
dem flock() (d.h. vor dem ersten write()) wohl in keinem Fall, auch
wenn mein open(2)-Manpage meint: "O_APPEND - The file is opened in
append mode. Before each write(), the file offset is positioned at the
end of the file, as if with lseek()."
Paul Hink wrote:
> Ferry Bolhar
>>
>>Die meisten Betriebssysteme implementieren flock() (den Systemcall)
>>als "advisory locking", d.h., es wird erwartet, dass alle Prozesse,
>>die auf eine gemeinsam genutzte Datei zugreifen wollen, vor dem
>>open() ein flock() absetzen und damit prüfen, ob ein Zugriff möglich
>>ist.
>
> Nein, denn das geht nicht. flock() arbeitet mit einem Filehandle, d.h.
> du *musst* die Datei zunächst per open() öffnen und kannst erst dann
> das flock() aufrufen.
Richtig. Ferry doziert, ohne flock() jemals angewendet zu haben :)
> Und wenn man die Datei im Append-Mode öffnet, schadet ein seek(FOO, 0,
> 2) - wie von der Perl-flock-Dokumentation vorgeschlagen - direkt nach
> dem flock() (d.h. vor dem ersten write()) wohl in keinem Fall, auch
> wenn mein open(2)-Manpage meint: "O_APPEND - The file is opened in
> append mode. Before each write(), the file offset is positioned at the
> end of the file, as if with lseek()."
Ja, das seek() im Beispiel ist Paranoia-Code,
meiner Ansicht nach unnötig.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
"Paul Hink"
> Natürlich sollte man die zu "schützenden" Filehandle-Zugriffe
> erst nach einem erfolgreichen flock() machen
Ah! Ich glaube, jetzt komme ich dahinter:
Wenn flock() = true ist, bedeutet das nicht nur, dass ich
die Datei erfolgreich vor fremden Zugriffen sichern konnte,
sondern gleichzeitig auch, dass die Datei zur Zeit von keinem
anderen Programm gelockt wurde. Sehe ich das so richtig?
Paul Lenz
Paul Lenz wrote:
> "Paul Hink"
>>
>>Natürlich sollte man die zu "schützenden" Filehandle-Zugriffe
>>erst nach einem erfolgreichen flock() machen
>
> Ah! Ich glaube, jetzt komme ich dahinter:
>
> Wenn flock() = true ist, bedeutet das nicht nur, dass ich
> die Datei erfolgreich vor fremden Zugriffen sichern konnte,
> sondern gleichzeitig auch, dass die Datei zur Zeit von keinem
> anderen Programm gelockt wurde. Sehe ich das so richtig?
Für einen Exklusiv-Lock ist das richtig. Bei einem
Shared-Lock können u.U. mehrere Prozesse einen Lock halten.
Lesetipp:
$ perldoc perlopentut
Abschnitt "File Locking"
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
"Frank Seitz"
>> Wenn flock() = true ist, bedeutet das nicht nur, dass ich
>> die Datei erfolgreich vor fremden Zugriffen sichern konnte,
>> sondern gleichzeitig auch, dass die Datei zur Zeit von keinem
>> anderen Programm gelockt wurde. Sehe ich das so richtig?
>
> Für einen Exklusiv-Lock ist das richtig.
Vielen Dank. Damit ist meine Frage beantwortet, den Rest
kriege ich hoffentlich allein hin.
> Bei einem Shared-Lock können u.U. mehrere Prozesse
> einen Lock halten.
Da sehe ich ehrlich gesagt keinen Sinn drin. Ich will verhindern,
dass zwei Programme sich die selbe Datei gegenseitig kaputt
machen. Deshalb wird richtig gelockt oder gar nicht.
Paul Lenz
Paul Lenz wrote:
> "Frank Seitz"
>>
>>Bei einem Shared-Lock können u.U. mehrere Prozesse
>>einen Lock halten.
>
> Da sehe ich ehrlich gesagt keinen Sinn drin.
Nur weil du keinen Sinn siehst, heißt nicht, dass
keinen Sinn gibt.
> Ich will verhindern,
> dass zwei Programme sich die selbe Datei gegenseitig kaputt
> machen. Deshalb wird richtig gelockt oder gar nicht.
Was "richtiges" Locking ist, richtet sich nach dem Anwendungsfall.
Dein Anwendungsfall (wie immer der aussehen mag) ist
gewiss nicht der einzig mögliche.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Paul Lenz
> "Frank Seitz"
>> Bei einem Shared-Lock können u.U. mehrere Prozesse einen Lock
>> halten.
>
> Da sehe ich ehrlich gesagt keinen Sinn drin.
Anwendungsbeispiel: Es gibt eine Datei, auf die einige Prozesse
schreibend und einige lesend zugreifen müssen. Alle die, die schreiben
müssen, brauchen natürlich einen Exclusive Lock, um keinen Datensalat
zu produzieren. Mehrere ausschließlich lesende Prozesse stören sich
dagegen nicht, die können ruhig gleichzeitig mit der Datei arbeiten,
solange ausgeschlossen ist, dass es gleichzeitig Schreibzugriffe gibt.
Also gilt in diesem Fall:
- Schreibzugriff erfordert einen Exclusive Lock, denn davon kann es pro
Datei zu jedem Zeitpunkt nur einen geben und keine gleichzeitigen
Shared Locks.
- Lesesezugriff erfordert einen Shared Lock, davon kann es pro Datei
mehrere gleichzeitig geben, aber keinen gleichzeitigen Exclusive
Lock.
Paul Lenz:
>> Bei einem Shared-Lock können u.U. mehrere Prozesse
>> einen Lock halten.
>
> Da sehe ich ehrlich gesagt keinen Sinn drin. Ich will verhindern,
> dass zwei Programme sich die selbe Datei gegenseitig kaputt
> machen. Deshalb wird richtig gelockt oder gar nicht.
Wenn mehrere Prozesse die Datei lesen wollen, können
sie das auch gleichzeitig tun. Daher machen in solchen
Fällen shared locks Sinn. Das Aufsetzen eines shared
Locks verhindert dann, dass ein Prozess, der die Datei
beschreiben möchte, das kann, gestattet aber anderen
Prozessen das Lesen der Datei.
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Frank Seitz:
>> Nein, denn das geht nicht. flock() arbeitet mit einem Filehandle, d.h.
>> du *musst* die Datei zunächst per open() öffnen und kannst erst dann
>> das flock() aufrufen.
>
> Richtig. Ferry doziert, ohne flock() jemals angewendet zu haben :)
Doch, habe ich. Das ist ja gerade das Problem...
Dennoch muss ich mich entschuldigen - die von mir beschriebene
Variante von flock, das auch Dateinamen akzeptiert, gibt es nur
unter Tru64 (Digital UNIX) und unter VMS (wo es nur mandatory
locking gibt). Als ich mein Posting schrieb, hatte ich ein
entsprechendes Tru64 Codebeispiel vor Augen. Ich habe dann nicht
mehr darauf geachtet, dass dieses flock in Perl natürlich
nicht standardmäßig dabei ist, sondern über ein Modul geladen
werden muss. Mea culpa, mea maxima culpa.
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf@wien.gv.at
Post removed (X-No-Archive: yes)