FileToString: Wie String zu "StringToFile?"

[Go2EITS]

@marabu
Vielen Dank für Deine Antwort, meine Routinen kopieren exakt.
Die Files sind im Original und als Backup unverändert.

Const funtioniert. Warum soll ich ein Const nehmem. Für mich ungewohnt...

[marabu]

Mein letzter Versuch: du schreibst in Zeile 9 der Prozedur StringToFile() aus deinem Beitrag #9 eine Längeninformation in die Datei, welche beim Einlesen noch nicht vorhanden ist. Dadurch haben die gelesene Datei und die geschriebene Datei nicht mehr den gleichen Inhalt. Bin ich denn der einzige hier, der das sieht?

Das Schlüsselwort CONST in der Signatur von StringToFile() dokumentiert für den kundigen Leser, dass die Argumente der Prozedur garantiert nicht inhaltlich verändert werden. In Verbindung mit dem Datentyp String erlaubt diese Vorgehensweise dem Compiler gewisse Optimierungsmaßnahmen zu ergreifen.

Grüße vom marabu

[Go2EITS]

Ok, auch in der Gefahr dass ich es nicht verstanden habe, damit können wir aber beide gut Leben, marabu.

Du meinst eine Datei, die wohl offen ist, bzw. während des Schreibens sich verändert.
Dann kann der geschreibene Stream nicht stimmen. Klar. Aber das Problem kenne ich.
Eine FileInUse lösch das Problem auch nicht. Nur ein Backup via Linux/BartCD. Aber in meinem Falle wäre es mit Spatzen auf Kanonen, sorry, anders rum, schießen. OK?

Zitat:

Das Schlüsselwort CONST in der Signatur von StringToFile() dokumentiert für den kundigen Leser, dass die Argumente der Prozedur garantiert nicht inhaltlich verändert werden. In Verbindung mit dem Datentyp String erlaubt diese Vorgehensweise dem Compiler gewisse Optimierungsmaßnahmen zu ergreifen.

An Klarheit und Exaktheit eine hervorrangende Erklärung! TOP!

Danke für Deine Mühe, marabu!
Go2EITS

[Leonard]

Zitat:

Zitat von marabu

Mein letzter Versuch: du schreibst in Zeile 9 der Prozedur StringToFile() aus deinem Beitrag #9 eine Längeninformation in die Datei, welche beim Einlesen noch nicht vorhanden ist. Dadurch haben die gelesene Datei und die geschriebene Datei nicht mehr den gleichen Inhalt. Bin ich denn der einzige hier, der das sieht?

Auf die Frage hin hab ich mir die Prozedur auch nocheinmal angeschaut. Stimmt, hast Recht. So wie es da steht wird vor dem übergebenen Str die Länge dessen geschrieben. Das die Dateien auf diese Art und Weise danach wirklich gleich sind kann ich auch nicht glauben. Habs aber ehrlich gesagt selber nicht probiert. Also marabu, musst nicht an dir zweifeln :-D
Schönen Abend noch... Leonard

[Go2EITS]

Neues Problem:
Der Code Filetostring und Stringtofile scheint die gelesen Daten auf der Festplatte noch offen zu haben; das Löschen geht nur, wenn mein Programm, das die Daten eingelesen hat, geschlossen wird. Gibt es ein Close dazu? Ich habe bei den Streams nachgesehen, konnte aber nichts finden.

@marabu
Ich habe mir den Code auch angesehen: Der Code schreibt in die Backups die Länge an den Anfang. :pale: Ich kann obigen Code nicht mehr ändern:
Also den Code verwenden:

Delphi-Quellcode:

function FileToString(const FileName: string): AnsiString;// inline; 
var 
  fs: TFileStream; 
  Len: Integer; 
begin 
  fs := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite); 
  try 
    Len := fs.Size; 
    SetLength(Result, Len); 
    if Len > 0 then 
      fs.ReadBuffer(Result[1], Len); 
  finally 
    fs.Free; 
  end; 
end;

Procedure StringToFile(const FileName, Str: string);//Inline; 
var 
  fs: TFileStream; 
  Len: Integer; 
begin 
  fs := TFileStream.Create(FileName, fmcreate); 
  try 
    Len := Length(Str); 
    // fs.Write(Len, SizeOf(Integer)); Raus damit!!!!!!
    fs.Write(Str[1], Len); 
  finally 
    fs.Free; 
  end; 
end;

Vielen Dank Marabu, Dein Einwand war absolut berechtigt! :thumb:


Gruß
Go2EITS

[Go2EITS]

Guten Morgen DP!
Das Problem besteht noch:

Zitat:

Der Code Filetostring und Stringtofile scheint die gelesen Daten auf der Festplatte noch offen zu haben; das Löschen geht nur, wenn mein Programm, das die Daten eingelesen hat, geschlossen wird. Gibt es ein Close dazu? Ich habe bei den Streams nachgesehen, konnte aber nichts finden.

Ich habe in der Hilfe nochmals nachgesehen: Ein FileClose soll helfen. Ich habe daher, wie "beschrieben" (ohne weiteren Hinweis oder ein Beispiel), nach dem fs.free in der StringtoFile ein Fileclose(fs.handle); eingefügt:

Delphi-Quellcode:

Procedure StringToFile(const FileName, Str: string);//Inline; 
var 
  fs: TFileStream; 
  Len: Integer; 
begin 
  fs := TFileStream.Create(FileName, fmcreate); 
  try 
    Len := Length(Str); 
    fs.Write(Str[1], Len); 
  finally 
    fs.Free; 
    Fileclose(fs.handle); //Das funzt net!  
end; 
end;

Das bringt mir eine Exception. :gruebel:
Kann es sein, dass ich beim Lesen z. B. von 900 Files hintereinander mit "FileToString" auch alle Handles holen muss und daher nur ein, nämlich das letzte Handle, schließe?
Oder kann es sein, dass ich das Handle beim Lesen noch offen habe? Wie gesagt: Streams sind für mich Neuland.

Hat da jemand einen Ansatz zur Lösung? :gruebel:
Vielen Dank für Eure Mühe (Mit der Lösung kommt dann auch Delphi Clean 1.2 Beta ohne dem Beta für Euch raus! :zwinker:
Beste Grüße
Go2EITS

[marabu]

Guten Morgen.

Du musst an einer anderen Stelle suchen - der Destruktor von TStream gibt das file handle frei.

Grüße vom marabu

[Go2EITS]

Guten Morgen marabu,

es kann sein, dass dies (mit dem Handle) der Fehler nicht ist? Im Internet finde ich nirgends ein Fileclose in Verbindung zu den Stream Beispielen. Die Aktionen werden im Regelfall mit Free geschlossen/beendet . Da sich sonst niemand meldet, scheint das Problem mit dem Handle wohl nicht die Ursache und auch ein Fileclose nocht notwendig zu sein.

Vielleicht ist ja Deletefile(Filename) der Verursacher und nicht die Streams. Ich kann mir daher keinen Reim machen, wieso die Verzeichnisse via Explorer nicht löschbar sind, wenn mein Programm noch offen ist, aber alle Aktionen korrekt ausgeführt hat. Ich greife auf diese Quellverzeichnisse nur mit StringtoFile und Deletefile darauf zu. :gruebel:

Beste Grüße
Go2EITS

[Hawkeye219]

Hallo Go2EITS,

hast du vielleicht in deinem Code ein "FindFirst" ohne abschließendes "FindClose" benutzt? Das könnte eine Erklärung für die Fehlermeldung des Explorers sein.

Gruß Hawkeye

[marabu]

HAllo,

noch eine Hilfe zur Selbsthilfe: Der Process Explorer von SysInternals zeigt, wenn man die eigene Anwendung selektiert, welche Resourcen (noch) zugeordnet sind. Zusammen mit dem integrierten Debugger der Delphi IDE sollte es ein Leichtes sein, die fehlerhaften Code-Strecken zu identifizieren.

Grüße vom marabu