Recent

Author Topic: Text file problem  (Read 3407 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14159
  • Probably until I exterminate Putin.
Re: Text file problem
« Reply #15 on: November 25, 2020, 06:26:32 am »
There is also some Pascal code around. I seem to remember Bart? has some code.
There is also Pascal code for whoislocking.
I used it in the past, I guess it is win32 only.
Specialize a type, not a var.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Text file problem
« Reply #16 on: November 25, 2020, 07:25:02 am »
    Everything compiles fine though I had to change assign and close to assignfile and closefile respectively.
That should - almost - never be the case. You do not need xxxFile in most cases, just system and no dependency on sysutils.
But it does not hurt, except larger binaries.

It's necessary to rename calls to Assign to System.Assign or AssignFile inside descendants of TPersistent due to their own Assign method and Close to System.Close or CloseFile inside descendants of TCustomForm due to its own Close method.

Also the *File overloads are part of the ObjPas unit, not SysUtils and are only really forwarders, so that don't hurt that much.

loaded

  • Hero Member
  • *****
  • Posts: 824
Re: Text file problem
« Reply #17 on: November 25, 2020, 07:35:58 am »
A simple solution method I use for problems that may occur in systemic situations that improve after a certain period of time;

Code: Pascal  [Select][+][-]
  1. procedure TForm1.Button1Click(Sender: TObject);
  2. var
  3.   err:Boolean=false;
  4. begin
  5.   repeat
  6.     try
  7.     // Start of Creation, Deletion Operations
  8.     //....................
  9.     //....................
  10.     //....................
  11.     //....................
  12.     //....................
  13.     //....................
  14.     //....................
  15.     //....................
  16.     //End of Creation, Deletion Operations
  17.     err:=false;
  18.     except
  19.       on E : Exception do
  20.       begin
  21.       err:=true;
  22.       caption:=E.ClassName+' error raised, with message : '+E.Message;
  23.       end;
  24.     end;
  25.     Application.ProcessMessages;
  26.   until not err;
  27.   caption:=' Transaction Completed Successfully' ;
  28. end;  
  29.  
Check out  loaded on Strava
https://www.strava.com/athletes/109391137

Thaddy

  • Hero Member
  • *****
  • Posts: 14159
  • Probably until I exterminate Putin.
Re: Text file problem
« Reply #18 on: November 25, 2020, 09:06:09 am »
Since he is using old school IO routines I strongly disagree with using exceptions in this case.
Both code bloat and slow in a loop that can be predicted to fail sometimes.
Although Marco's code is also predictably slow because of his long timeout value, as he wrote himself.
« Last Edit: November 25, 2020, 09:09:30 am by Thaddy »
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Text file problem
« Reply #19 on: November 25, 2020, 09:10:36 am »
Since he is using old school IO routines I strongly disagree with using exceptions in this case.
Both code bloat and slow in a loop that can be predicted to fail sometimes.
Although Marco's code is also predictably slow because of his long timeout value, as he wrote himself.

In my experience these locks range from 50ms to 500ms. Retrying immediately then only causes busywaiting. This is the reason for the timeouts.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Text file problem
« Reply #20 on: November 25, 2020, 08:30:49 pm »
    Thanks winni, for looking for that C code. The code that I got from this thread was a valiant effort and I'm very appreciative but testing showed that they will not work except to tell you if a file is open or not. Like you say, aside from very hard-to-find solutions the only way to delete a text file is to first close it and to close you have to know what TextFile variable opened it.
    I changed my program so that the text files that I had trouble with are created by an external program that is launched by the main program. When the external program closes then the files are freed up. After the files are created then there is only one page in the main program that opens them and it opens them for reading only. The only other thing that is done to them is to delete them.
    I still don't know what caused the text files to have an open status but I think that the error is fixed. If I have any more problems then I'll use try statements to make sure that the files are closed before they are deleted, using the TextFile variables that I know opened them. If a file is open then the try statement will close it. If it's not open then the exception error is handled by the try statement and no harm is done.

dseligo

  • Hero Member
  • *****
  • Posts: 1177
Re: Text file problem
« Reply #21 on: November 27, 2020, 01:38:32 am »
Like you say, aside from very hard-to-find solutions the only way to delete a text file is to first close it and to close you have to know what TextFile variable opened it.
From this I assume you are opening multiple files or using multiple variables for files. This opens possibility that some file is not closed because of an error in your program. I suggest that you log in a file all you opening and closing files along with variable names (and/or maybe unique ID). When error occurs you take that file and look for pairs - an unmatched pair is location of you problem.

Something like this:
Code: Pascal  [Select][+][-]
  1. const LogName='mylog.txt';
  2.  
  3. procedure LogInit;
  4. var fLog:TextFile;
  5. begin
  6.   AssignFile(fLog,LogName);
  7.   Rewrite(fLog);
  8.   CloseFile(fLog);
  9. end;
  10.  
  11. procedure Log(s:String);
  12. var fLog:TextFile;
  13. begin
  14.   AssignFile(fLog,LogName);
  15.   Append(fLog);
  16.   WriteLn(fLog,FormatDateTime('yyyy-mm-dd hh:nn:ss.zzz ',Now),s);
  17.   CloseFile(fLog);
  18. end;
  19.  
  20. procedure MyCreateFile(var f:TextFile; sFileVarName, sFileName:String; ID:Integer);
  21. begin
  22.   AssignFile(f,sFileName);
  23.   Rewrite(f);
  24.   Log('create '+sFileVarName+' '+sFileName+' '+Inttostr(id));
  25. end;
  26.  
  27. procedure MyCloseFile(var f:TextFile; sFileVarName:String; ID:Integer);
  28. begin
  29.   CloseFile(f);
  30.   Log('close '+sFileVarName+' '+Inttostr(id));
  31. end;
  32.  
  33. ...
  34. LogInit; // at start of the program
  35. ....
  36.  
  37. //
  38. MyCreateFile(fTest,'fTest','testfile1.txt',1);
  39.  
  40. ...
  41.  
  42. MyCreateFile(fTest2,'fTest2','testfile2.txt',3);
  43.  
  44. ...
  45.  
  46. MyCloseFile(fTest,'fTest',2);
  47.  
  48. ...
  49.  
  50. MyCloseFile(fTest2,'fTest2',4);
  51.  

If you do this everywhere in your program where you use AssignFile, CloseFile, Rewrite, Reset or Append you should find if and where you left your file open.

user5

  • Sr. Member
  • ****
  • Posts: 357
"Text file problem" update
« Reply #22 on: December 01, 2020, 10:30:06 pm »
    On November 24 I posted a note ("Text file problem") about a problem I was having in which a text file that was legitimately closed by my program ended up being considered still open by Windows. marcov said "This is a known (Windows) issue". This problem was unpredictable and would only happen every once in a while but testing did show some interesting results. Sometimes when I run Windows Explorer I notice that its progress bar runs very, very slowly and never really ends, even going beyond the end of its containment box. Rebooting the computer usually fixes this.
    When the progress bar is behaving like this then the chances of the error occurring are vastly increased. My computer is a Windows 7 machine that was upgraded to Windows 10 and it seems to behave oddly at times. If I use YouTube a lot then the computer crashes, shutting itself off. I changed the power settings but it still happens if I play many YouTube videos.
    I did some research on the slow progress bar. I have been using Task Manager to check processing performance and I ended up changing Windows indexing options but I don't know if this is the solution to the text file problem.
    I did find an interesting Lazarus Forum topic titled "Delphi, Lazarus Pi Performance Benchmark" and I was wondering if it might be possible to programmatically do some kind of performance check before the program creates and uses those text files. My program is currently set up to provide work around options when the error happens but I haven't been able to solve the problem except by shutting the program down and thus freeing up the file/s involved.  I'm really just groping in the dark here.

dseligo

  • Hero Member
  • *****
  • Posts: 1177
Re: "Text file problem" update
« Reply #23 on: December 03, 2020, 01:27:48 am »
My computer is a Windows 7 machine that was upgraded to Windows 10 and it seems to behave oddly at times.
Are you experiencing this "Text file problem" only on this one computer?
If you have other issues with it, maybe it is time to reinstall Windows?

 

TinyPortal © 2005-2018