Log-Datei realisieren

[MatthiasR]

Zitat von Reinhard Kern:

EXCLUSIVE ist das entscheidende: ich habe es vorgeschlagen, hamamitsu hat damit eine ganze Beispielprozedur geschrieben und shmia hat eine Alternative mit TExclusiveFileStream vorgeschlagen, die intern das gleiche tut. Vielleicht sind wir ja blöd, aber immerhin sind wir schon zu dritt.

Da du nix verstanden hast, lässt du das entscheidende Statement mit fmShareExclusive einfach weg. So was nenne ich beratungsresistent.

Wenn du dich mal mit Dateien beschäftigen würdest, dann würdest du auch auf den Begriff "exklusiver Zugriff" stossen. Meine Meinung zum Thema: solange du diesen Punkt nicht verstanden hast, kannst du dein Problem nicht lösen - stattdessen auf Mutexe u.a. auszuweichen, ist Blödsinn, weil das das Problem nur anders einkleidet und dazu noch komplizierter ist als Datei-Zugriffe.

Natürlich hast du als Jungprogrammierer das Recht, alles anders zu sehen und alle Erkenntnisse der IT mit Verachtung zu strafen. Schon ein Konkurrent weniger.

Gruss Reinhard

Das mit dem exclusiven Öffnen der Log-Datei habe ich schon verstanden, jedoch bin ich davon ausgegangen, dass das bei Windows bei schreibenden Zugriffen automatisch so gesteuert wird. Und Append ist für meine Begriffe ja ein schreibender Zugriff. Diese Annahme wurde für mich dadurch bekräftigt, dass ein schreibendes Öffnen ein und derselben Datei mittels Append eben NICHT durch mehrere Programme gleichzeitig möglich ist, sondern in einer Exception endet. Auch ohne diese besagte Zeile!!! Das einzige, was ich daher von euch wissen wollte, ist, was das vorige setzten des FileMode genau bewirkt. Für mich ergeben sich zumindest bei mir KEINE sichtbaren Änderungen, wenn ich diese Zeile einfüge!!! Mein Programm verhält sich kein Stück anders, als wenn ich die Zeile weglasse. Deswegen wollte ich es genau wissen, was intern abgeht, bevor ich diese Zeile blindlings übernehme. Ich hoffe, du siehst es mir nach, dass ich Dinge lieber erstmal hinterfrage. Genauso bei shmias Klasse. Wenn ich selbst eine Lösung gefunden habe, die zwar womöglich nicht ganz so komfortabel ist, jedoch ihren Dienst verrichtet, auf meinem eigenen Mist gewachsen ist und ich daher auch 100%ig durchsteige, was da intern eigentlich abläuft, dann ziehe ich diese Lösung vor.

Also frage ich nochmal: was bewirkt die ZeileFileMode := fmOpenReadWrite or fmShareExclusive; genau? Was ist anders, wenn ich die Zeile einfach weglasse? Mein Programm verhält sich wie gesagt genauso...

[Hansa]

Zitat von Infect:

..dass ein schreibendes Öffnen ein und derselben Datei mittels Append eben NICHT durch mehrere Programme gleichzeitig möglich ist...

So ist es. Es geht um eine einzelne Datei. Noch nie in Word die Meldung gesehen : "Dokument von anderem Benutzer im Zugriff ! Schreibgeschützt öffnen ?" oder so ähnlich ? Genau das ist der Punkt. Natürlich kann ich das umgehen, indem ich das eine Word-Dokument verlasse (oder die Log-Datei schließe) und dann den vorher geänderten und abgespeicherten Text neu öffne und dann eben nicht schreibgeschützt. Der ganze Firlefanz entfällt bei Einsatz einer Datenbank. Wenn einige auch Logdatei mit Textdatei gleichsetzen, es geht damit nur so : Öffnen (Append), schreiben, schließen. Im Zeitraum zwischen öffnen und schließen kann KEIN anderer Benutzer etwas schreiben !!

[himitsu]

per Default ist MileMode nur auf fmOpenReadWrite gesetzt (in der Unit System)

also werden Dateien damit nicht exlusiv geöffnet.

Zitat von Infect:

jedoch bin ich davon ausgegangen, dass das bei Windows bei schreibenden Zugriffen automatisch so gesteuert wird.

indows macht nichts automaisch (wär ja auch noch schöner, weil sonst wüßte man ja nicht was windows wann machen würde), das muß man schon selber angeben.

Zitat von Infect:

Und Append ist für meine Begriffe ja ein schreibender Zugriff.

jupp, isser

Zitat von Infect:

Diese Annahme wurde für mich dadurch bekräftigt, dass ein schreibendes Öffnen ein und derselben Datei mittels Append eben NICHT durch mehrere Programme gleichzeitig möglich ist, sondern in einer Exception endet. Auch ohne diese besagte Zeile!!!

mein Tipp, wenn du uns nicht glaubst:
versuch doch einfach mal eine Datei mehrmals zu öffnen.

Zitat von Infect:

Das einzige, was ich daher von euch wissen wollte, ist, was das vorige setzten des FileMode genau bewirkt.

das wurde doch schon mehrmals gesagt.

Zitat von Infect:

Für mich ergeben sich zumindest bei mir KEINE sichtbaren Änderungen, wenn ich diese Zeile einfüge!!!

nicht?

Zitat von Infect:

Also frage ich nochmal: was bewirkt die ZeileFileMode := fmOpenReadWrite or fmShareExclusive; genau? Was ist anders, wenn ich die Zeile einfach weglasse? Mein Programm verhält sich wie gesagt genauso...

siehe oben (da per Default nicht gesetzt)


aber de Witz Dabei, ich hab es eben selbst mal ausprobiert und war "geschockt"
im Delphi 7 hier wird die Datei bei Schreibzugriff (Rewrite oder Append) immer im exklusiven Modus geöffnet, selbst wenn der nicht angegeben ist.

Und besonsters geschockt war ich, als ich selber angegeben hab, daß mit Sharing-Rechten (nicht Exklusiv) geöffnet werden sollte

Ich würde das jetzt mal ganz einfach als Delphifehler auslegen
und dazu raten dieses lieber nicht auszunutzen/vorauszusetzten (wer weiß ob/wann das mal repariert wird/wurde)


eigentlich müßte das Erste ohne Exception durchlaufen und das Zweite wie gewollt bei Append(F2); eine Exception auslösen.

Delphi-Quellcode:

Var F, F2: TextFile;

Begin
  // testdatei erstellen
  AssignFile(F, 'test.txt');
  Rewrite(F);
  CloseFile(F);

  //FileMode := fmOpenReadWrite or fmShareDenyNone;

  // mit sharing-rechten
  AssignFile(F, 'test.txt');
  Append(F);

  AssignFile(F2, 'test.txt');
  Append(F2);
  CloseFile(F2);

  CloseFile(F);



  FileMode := fmOpenReadWrite or fmShareExclusive;

  // exklusiv
  AssignFile(F, 'test.txt');
  Append(F);

  AssignFile(F2, 'test.txt');
  Append(F2);
  CloseFile(F2);

  CloseFile(F);
End;

[MatthiasR]

Zitat von himitsu:

...aber de Witz Dabei, ich hab es eben selbst mal ausprobiert und war "geschockt"
im Delphi 7 hier wird die Datei bei Schreibzugriff (Rewrite oder Append) immer im exklusiven Modus geöffnet, selbst wenn der nicht angegeben ist.

Und besonsters geschockt war ich, als ich selber angegeben hab, daß mit Sharing-Rechten (nicht Exklusiv) geöffnet werden sollte

Ich würde das jetzt mal ganz einfach als Delphifehler auslegen
und dazu raten dieses lieber nicht auszunutzen/vorauszusetzten (wer weiß ob/wann das mal repariert wird/wurde)...

AHA, da liegt also der Hund begraben! Ich hoffe jetzt versteht jeder von euch (v.a. du Reinhard!!!) warum mir nicht einleuchten wollte, warum ich unbedingt den FileMode umstellen muss, wenn es ohne genauso funktioniert (weil der FileMode wie ihr seht scheinbar standardmäßig auf Exclusive umgestellt wird). Da wurde mein Programm wohl etwas vorschnell als "reiner Unsinn" abgestempelt, wenn man es wie mir scheint zuvor nicht einmal selbst ausprobiert hat! Eigentlich wäre da ne Entschuldigung fällig...

Wie dem auch sei: danke himitsu, dass du der Sache auch mal auf den grund gegangen bist! So stellt sich das alles für mich in einem ganz neuen Licht dar! Wenn man wirklich davon ausgeht, dass es sich bei diesem Verhalten um einen Delphi-Fehler handelt, dann ergibt das explizite Umstellen (und Rückstellen!!!) des FileMode durchaus einen Sinn, das sehe ich absolut genau so! Seht ihr, man kann mich durchaus überzeugen (so viel zum Thema "Jungprogrammierer" und "Erkenntnisse der IT"...).

[himitsu]

Zitat von Infect:

dann ergibt das explizite Umstellen (und Rückstellen!!!) des FileMode durchaus einen Sinn

also das vorherige Speichern und nachfolgende Zückstellen MUß nicht unbedingt gemacht werden
FileMode ist leider eine Progamminterne Variable und wird in allen nachfolgenden Reset/Rewrite/Append-Aufrufen werwendet.
Wenn also irgendwo anders im Programm wieder eine Datei geöffnet wird, dann wäre es besser wenn man da den alten Wert wiederherstellt, da es da sonst zu problemen kömmen kann (wenn dort ein anderer oder der Standardwert benötigt wird)

nja, das Schlimme daran ist eigentlich daß man aufgrund dieses Fehlers keine Dateien mehrfach öffnen kann, selbst wenn man wöllte
(na ja, zum Glück hab ich mich da komplett auf die WinAPI umgestellt und dort läuft alles wie gewünscht ^^)

[MatthiasR]

Nach nochmaligem Studiums der Delphi-Hilfe möchte ich einfach mal ins blaue rein behaupten, dass das Verhalten sogar gewollt ist und keinen Delphi-Fehler darstellt. Aber lest selbst:

Zitat von Delphi-Hilfe:

Die Variable gibt den Zugriffsmodus für typisierte und nicht typisierte Dateien an, die mit Reset geöffnet werden.

Unit

System

Kategorie

Ein-/Ausgabe

Delphi-Syntax:

var FileMode: Byte = 2;

Beschreibung

In Delphi legt FileMode den Zugriffsmodus fest, wenn typisierte und nicht typisierte Dateien (keine Textdateien) mit der Prozedur Reset geöffnet werden.

Der Standardwert von FileMode ist 2 (Schreib-/Lesezugriff). Wenn Sie dieser Variablen einen anderen Wert zuweisen, wird der betreffende Modus bei allen folgenden Reset-Aufrufen verwendet. In der Unit SysUtils sind eine Reihe von Zugriffsmodus-Konstanten für Dateien deklariert, die der Variablen FileMode zugewiesen werden können.

Hinweis: Setzen Sie FileMode unbedingt zurück, bevor Sie Reset für eine schreibgeschützte Datei aufrufen. Auch wenn die Datei nur gelesen werden soll, verursacht der Standardwert von FileMode (Schreib-/Lesezugriff), dass das Öffnen einer schreibgeschützten Datei fehlschlägt.

Warnung: FileMode ist als Variable deklariert, nicht als threadvar. Deshalb ist diese Variabel nicht thread-sicher.

Hier ist nur von Reset die Rede, NICHT von Rewrite oder Append. D.h. so wie ich die Sache sehe, ist die Variable "FileMode" nur für lesenden Zugriff gedacht, und da ist es ja auch sinnvoll, da lesend standardmäßig ja beliebig viele Instanzen auf eine Datei zugreifen können. Wenn man das nicht möchte, dann kann man sich mit dem vorigen Umstellen des FileMode behelfen.

Beim schreibenden Zugriff finde ich es jedoch schon sinnvoll, dass immer nur EINE Instanz auf eine Datei zugreifen kann. Und mir fällt leider auch kein sinnvolles Beispiel ein, bei dem ein andres Verhalten - so wie von dir gewünscht - einen Sinn ergibt. Kannst du mir eines nennen?

Wieder anders ist es, wenn eine Instanz schreibend, eine zweite lesend die Datei öffnen will, das müsste man fast mal ausprobieren, wie Delphi sich dort verhält, jedoch ist das für meinen Anwendungsfall ja irrelevant.

[Reinhard Kern]

Zitat von Infect:

Nach nochmaligem Studiums der Delphi-Hilfe möchte ich einfach mal ins blaue rein behaupten, dass das Verhalten sogar gewollt ist und keinen Delphi-Fehler darstellt. Aber lest selbst...

Hallo,

ich programmiere zwar schon solange Pascal wie es das gibt, aber ich würde nie behaupten, alles zu wissen - z.B. welche File Modes Delphi ohne Anweisung setzt; ich benutze praktisch ausschliesslich Win32 für File-Operationen (in dem Fall OpenFile), weil da alles einstellbar ist und Windows das dann auch so macht wie ich es wollte. Aber das nur nebenbei, zunächst bin ich ja von deiner Fragestellung ausgegangen, weil du der Meinung warst, der Code in deinem Posting Nr. 1 funktioniere nicht, aber:

Wenn das alles so automatisch funktioniert wie zuletzt in den Postings beschrieben, dann hattest du doch vom ersten Posting an überhaupt kein Problem - oder sehe ich das auch falsch?

Eine Meinung noch dazu: die Ur-Pascal-Routinen Reset usw. haben den Anschluss an die Neuzeit weitgehend verpasst, das wurde durch Ergänzungen wie FileMode auch nur unzureichend repariert - kann auch nicht sein, damals gab es noch keine Lese-, Schreibrechte usw. Ich ersetze daher alle noch vorhandenen Aufrufe bei Gelegenheit durch die BS-Aufrufe wie OpenFile, WriteFile usw., damit hätte ein grosser Teil der Diskussion garnicht entstehen können. Das würde ich auch so weiterempfehlen.

Gruss Reinhard

[MatthiasR]

Zitat von Reinhard Kern:

...ich programmiere zwar schon solange Pascal wie es das gibt, aber ich würde nie behaupten, alles zu wissen...

Deine Äusserungen von oben hinterlassen bei mir aber leider einen ganz anderen Eindruck:

Zitat von Reinhard Kern:

...dadurch, dass du das einfach weglässt, ist dein Entwurf reiner Unsinn. Du hast weder meinen noch den Beitrag himitsus auch nur annähernd verstanden. Vielleicht solltest du mal ganz einfach anfangen "watt is eine Datei"...

Zitat von Reinhard Kern:

Da du nix verstanden hast, lässt du das entscheidende Statement mit fmShareExclusive einfach weg. So was nenne ich beratungsresistent.

Zitat von Reinhard Kern:

Natürlich hast du als Jungprogrammierer das Recht, alles anders zu sehen und alle Erkenntnisse der IT mit Verachtung zu strafen. Schon ein Konkurrent weniger.

Ich warte übrigens immernoch auf eine Entschuldigung. Ich denke, das würde sich so gehören, auch wenn ich im Vergleich zu dir was die Programmiererfahrung angeht ein kleiner Fisch sein mag.

Zitat von Reinhard Kern:

Wenn das alles so automatisch funktioniert wie zuletzt in den Postings beschrieben, dann hattest du doch vom ersten Posting an überhaupt kein Problem - oder sehe ich das auch falsch?

Nein, das siehst du nicht falsch. Das hat sich aber wie du siehst alles erst im Nachhinein herausgestellt. Auch ich war mir nicht sicher, ob mein Ansatz aus dem ersten Post der richtige ist oder ob sich dabei zwei Programme nicht doch in die Quere kommen können. Deswegen habe ich das ja gefragt. Außerdem wollte ich noch einen Lösungsansatz erfragen, für den Fall, dass zwei Programme exakt gleichzeitig in die Log-Datei schreiben wollen. Der Ansatz (kurz Schlafen legen und dann nochmals probieren) wurde mir geliefert und ich habe ihn dankend angenommen.

Für deinen Rat, vielleicht doch besser auf die Funktionen der Win32-API zurückzugreifen, bin ich dir angesichts der entstandenen Probleme und Unklarheiten jedoch dankbar. Ist vielleicht doch der bessere Weg (siehst du, ich bin ganz und gar nicht beratungsresistent!). Könntest du mir vielleicht schonmal verraten, welche Funktionen ich da für mein Vorhaben alle benötige (außer OpenFile und WriteFile)?

[shmia]

Ich glaube ich hab das schon öfters geschrieben und muss es wohl immer wieder tun:
Die Funktionen AssignFile(), Rewrite(), CloseFile(), readln(), writeln() stammen aus den Anfängen von
Pascal und sind daher veraltet.
Aus heutiger Sicht sind sie sogar eine Fehlkonstruktion.
Begründung:
Dateizugriff ist eine Aufgabe der Laufzeitbibliothek und darf nicht zum Sprachumfang einer höheren Progsprache selber gehören.
Ausserdem sind diese Funktionen gepuffert was heutzutage aber ein Nachteil ist, da das OS eh schon puffert.
Also Finger weg von den alten Funktionen und stattdessen Streams verwenden!!

[MatthiasR]

Zitat von shmia:

Ich glaube ich hab das schon öfters geschrieben und muss es wohl immer wieder tun:
Die Funktionen AssignFile(), Rewrite(), CloseFile(), readln(), writeln() stammen aus den Anfängen von
Pascal und sind daher veraltet.
Aus heutiger Sicht sind sie sogar eine Fehlkonstruktion.
Begründung:
Dateizugriff ist eine Aufgabe der Laufzeitbibliothek und darf nicht zum Sprachumfang einer höheren Progsprache selber gehören.
Ausserdem sind diese Funktionen gepuffert was heutzutage aber ein Nachteil ist, da das OS eh schon puffert.
Also Finger weg von den alten Funktionen und stattdessen Streams verwenden!!

Gut, dann nehme ich das jetzt mal als Anlass, mich endlich mal etwas mit Streams auseinanderzusetzen. Habe damit halt noch keinerlei Erfahrungen gemacht, aber das kann sich jetzt ja ändern. Und bestimmt verstehe ich danach auch deine Klasse etwas besser, dann könnte ich die doch für mein Problem einsetzen