Reading a text file error....99% it works fine, but 1% not!!!

[tullips]

This message I see a couple times a day in my error log.

6/27/2023 1:07:42 PM FomoTrain : - ES 09-23 - Path = c:\users\public\nt_daily-ES.txt - Error = System.UnauthorizedAccessException: Access to the path 'c:\users\public\nt_daily-ES.txt' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize, Boolean checkHost)
at System.IO.StreamReader..ctor(String path)
at NinjaTrader.NinjaScript.Indicators.ADS.ADSFomo.Fom oGetMACD(String WhatType)

he text contains the text True/False.

My code is this.

private bool FomoGetMACD(string WhatType)

{
string mySymbol = Instrument.FullName.Substring(0, 2); // easy and simple way to find out in which one we are
var path = @"c:\users\public\nt_"; // [email protected]";

bool retValue = false;

string line;

switch (mySymbol)
{
case "MY":
case "YM":
path = path + WhatType + "-YM.txt";
break;

case "ME":
case "ES":
path = path + WhatType + "-ES.txt";
break;

case "RT":
case "M2":
path = path + WhatType + "-RT.txt";
break;

case "NQ":
case "MN":
path = path + WhatType + "-NQ.txt";
break;
}

// Checks to see if the file exists
if (File.Exists(path))
{
// now we open the daily and get the results
/* The try-catch block is used for error handling.
In this case it is used to ensure you only have one stream object operating on the same file at any given moment. */
try
{
// Sets the file the StreamReader will read from
sr = new System.IO.StreamReader(path);
line = sr.ReadLine(); // this reads it as a text string with the 'newline'

retValue = bool.Parse(line); // and convert it to a boolean
}
catch (Exception e)
{
// Outputs the error to the log
Log("Path = " + path, NinjaTrader.Cbi.LogLevel.Error);
myPrint("Path = " + path + " - Error = " + e.ToString(), false, true);
}
finally
{
}
}
else
{
}

if (sr != null)
{
sr.Dispose();
sr = null;
}

return retValue; // default when we cannot find the file
}

I tried also ASYNC reading of the file but it did not made any difference. Now I force it to read after every bar is closed, but still this message appears.

Any inside would be appreciated, thanks -- Ronald

​

[NinjaTrader_ChelseaB]

Hello tullips,

This looks like a file access error, meaning there is a locking handle on the file while it is being read which has not been released on the next open.

You could instead keep the file open during the lifetime of the script without disposing so that you can continuously read from it. (And then dispose in State.Terminated)

[QuantKey_Bruce]

Most likely, if it is not a locking issue e.g. another copy of the script has the file open exclusively whlie you're trying to access it that 1% of the time, it will turn out to be an antivirus or antimalware issue where the time it takes that program to scan what you're writing to the file causes it to occasionally fail. I would recommend excluding that file or folder from live scanning if this is the case.

[tullips]

Hello Chelsea

If I am keeping the file open, would this then not be blocked for the other program to write into it?

I have a different charting program that is updating this file. And yes, I was thinking that both were trying to keep an hold on it, but I made sure the writing and reading happens at a different time slot.
And once it is written I actually have the file copied to a new file ie: es-60.txt -> nt_es-60.txt (and made sure I delete the old one first as well)

I will try the 'keep it open' and see if this would help.

[NinjaTrader_ChelseaB]

Hello tullips,

Keeping the file open would keep it locked, so no another program would not be able to write into it.

If you have multiple scripts or applications using the same file, this is most likely the issue.

[QuantKey_Bruce]

I don't think keeping the file open is the way to go. What you should do on the writing side is something like this:

(1) Instead of writing lines to a log file, instead, lock a List<string> and add the new line to the pending lines that need to be written then unlock the list.

(2) On a timer basis, in realtime only (not for historical bars), if there are any lines waiting to be written, attempt to get a lock on the file. If you get a lock on the ifle, lock the list, and write out all the pending lines and clear the list, unlock the list, and unlock the file. Do not keep the file open or locked any longer than it takes you to write out the lines from the pending line list. If you fail to get a lock on the file, do nothing, and wait for the next timer to check again.

On the reading side, you can on a timer basis attempt to open the file for reading, and if you can do so, read the entire file (or if you know you are only appending, read everything past the last length you read) and then close the file. If you are unable to open the file, continue using the contents you read previously.

The above described methodology is more robust and would avoid these types of problems.

[tullips]

Hi Bruce, what you propose is almost the same thing as I am doing right now, and it does work well, but the lock sometimes just get 'stuck' and I was hoping on a better, cleaner way to prevent this. And yes, I use timers, avoiding or trying to avoid locks, but sometimes I got a feeling it is locked in cache, and this is something I do not have control over. (flush does not always work)

The best thing I found so far was making sure the write and read time are far enough from each other, and I am happy this is not a time crucial info, as the 'change' happens in minimum each hour, but it was frustrating to see the errors and not able to fix it. It is however crucial to the strategy I use.

I tried the 'keep it open' but this actually created more issues then before. Having timers set away from each other is still the best way to go.

Thanks for responding you all