Filelock mit Config::IniFiles

[Reinhard Doberstein]

HAllo,

um eine automatische Abarbeitung von Daten zu ermöglichen muss ich zur Steuerung einige Daten extern speichern. Dabei will ich vermeiden das mehrere Prozesse auf diese Datei zugreifen.
D.h. klassischer Filelock: eigentlich also

open (FILE, "file.ext");
  flock(FILE,2);
    #do your stuff
  close(FILE);

Die Daten werden aber in .ini Dateien, d.h. im Windowsstyle, abgespeichert. Dazu benutze ich das Modul "Config::IniFiles". Dieses funktioniert so:

$cfg = Config::IniFiles->new( -file => "/path/configfile.ini" );
    # Daten lesen und schreiben
  $cfg->RewriteConfig();

Bei new() wird das komplette .ini gelesen, beim RewriteConfig() wird's komplett geschrieben. Alles dazwischen passiert im Speicher. Ein flock nach dem new() kommt also zu spät, da ein 2. Prozess dann schon die alten Daten gelesen hat.

Soweit verstanden?

Wie kann ich das umgehen/lösen?
Gibts vielleicht Alternativen zu "Config::IniFiles"? Aber alles per-hand zu manchen bin ich zu Faul :-)

Ach ja: Alles unter Windows.

By
Reinhard

[K@rl]

Hallo Reinhard,

irgendwie versteh' ich Dein Problem nicht - weil ja Dein Posting bereits die Lösung enthält:

open (FILE, "file.ext");
  flock(FILE,2);
    #do your stuff
  close(FILE);

$cfg = Config::IniFiles->new( -file => "/path/configfile.ini" );
    # Daten lesen und schreiben
  $cfg->RewriteConfig();

=
open (FILE, "file.ext");
flock(FILE,2);
#do your stuff
$cfg = Config::IniFiles->new( -file => *FILE );

Daten lesen und schreiben

$cfg->RewriteConfig();
close(FILE); # falls nach RewriteConfig() noch notwendig

Denn was lesen wir in der POD von Config::IniFiles zum -file Argument? .. na?:

-file filename

Specifies a file to load the parameters from. This 'file' may actually be any of the following things:
  1) a simple filehandle, such as STDIN
  2) a filehandle glob, such as *CONFIG
  3) a reference to a glob, such as \*CONFIG
  4) an IO::File object
  5) the pathname of a file

Also statt Variante 5) Variante 2) .. oder 1) oder 3) oder 4) .. man könnte auch sagen: alles *außer* 5;-)

Ach ja: Alles unter Windows.

Windows oder WinDOS (also Win95 & Co.) + mit welcher Perl Version? -- Ich frage nur, weil WinDOS sicher keine geeignete Multiuserumgebung ist und in ActiveState Perl < 5.6 ein flock() ohnehin nicht ging.

Mit einem herzlichen RTFM!
     K@rl

[Reinhard Doberstein]

open (FILE, "file.ext");
flock(FILE,2);
#do your stuff
$cfg = Config::IniFiles->new( -file => *FILE );

Daten lesen und schreiben

$cfg->RewriteConfig();
close(FILE); # falls nach RewriteConfig() noch notwendig

Aaaaa.

Denn was lesen wir in der POD von Config::IniFiles zum -file Argument? .. na?:

-file filename

Specifies a file to load the parameters from. This 'file' may actually be any of the following things:
  1) a simple filehandle, such as STDIN
  2) a filehandle glob, such as *CONFIG
  3) a reference to a glob, such as \*CONFIG
  4) an IO::File object
  5) the pathname of a file

Also statt Variante 5) Variante 2) .. oder 1) oder 3) oder 4) .. man könnte auch sagen: alles *außer* 5;-)

Danke, mir war nicht klar das das so geht.

Ach ja: Alles unter Windows.

Windows oder WinDOS (also Win95 & Co.) + mit welcher Perl Version?

NT4 mit ActiveState Perl 5.005

Ich frage nur, weil WinDOS sicher keine geeignete Multiuserumgebung ist und in ActiveState Perl < 5.6 ein flock() ohnehin nicht ging.

Dann werd ich wohl updaten. Das sollte kein Problem sein. Z.t. werden die Prozesse über den Webserver als CGIs angesprochen. Daher ist keine Aussage über das Zeitverhalten möglich, daher das Filelocking. Multiuser ist das aber daher nicht wirklich.

Mit einem herzlichen RTFM!

Jaja, lesen sollte man können :-/

By
Reinhard

[K@rl]

Hallo Reinhard,

NT4 mit ActiveState Perl 5.005

Den Update auf das Aktuelle ActiveState würde ich sehr empfehlen - nicht zuletzt, weil für 5.0.x von ActiveState keine neunen CPAN-Module mehr für deren ppm (Perl Package Manager) bereitgestellt werden. flock() müßte aber auch mit 5.005 + NT gehen.

"Upgrading is a pain", ich weiß, aber dieser Upgrade lohnt sich wirklich.

Multiuser ist das aber daher nicht wirklich.

Stimmt, denn NT ist zwar ein Multiprocess-, aber kein Multiuser-Betriebsystem.

Mit einem herzlichen RTFM!

War nicht böße gemeint :)

Ciao
   K@rl

[Reinhard Doberstein]

Mit einem herzlichen RTFM!
War nicht böße gemeint :)

hab ich auch nicht so verstanden.

By
Reinhard