FILE_SHARE_READ and FILE_SHARE_WRITE do not work proper. MQL creates buffers with different contents for the same file.
Please watch the example. It´s one of these "Sometimes bugs". If you cannot provoke the shown output, play around with the lines, add more FILE_SEEKs or change the filename. If you suspect the macro FILE_WRITE_STRING ... it´s ok, I can provoke the error also without it. But I had to play around with the code until the error was shown. Once the error occurs, you will never get rid of it until the filename is changed. This is really not funny.
This is the output, which it should never be, but which is it in almost all cases
It can only be fixed, when the file-handle, which is used for reading, is closed and reopened. In other words, FILE_SHARE_WRITE seems to work, but FILE_SHARE_READ does not.
Is your real use case really using 2 handles on the same file from 1 running EA ?
Why are you opening both handles with READ and WRITE when you only write from 1 handle ?
And by the way I can't reproduce the issue. If you don't provide a way to reproduce I doubt it will ever be fixed.
Is your real use case really using 2 handles on the same file from 1 running EA ?
Why are you opening both handles with READ and WRITE when you only write from 1 handle ?
And by the way I can't reproduce the issue. If you don't provide a way to reproduce I doubt it will ever be fixed.
- Of course its not designed to work with two handles in one EA, its rather for sharing data between several instances of one EA and for sharing data between indicators and EAs.
- I open both RW just to simulate the reality. The final EAs/indicators etc. do write and read
- But as you see, others could also reproduce it.
btw thx @ comeero for trying this out too.
For me the error happens as well. First run of the EA / indicator with the sample code above was fine but the error started with the second run and could only be resolved by deleting the file.
Same here, it works if the file didn't exist, but as soon as the sample is run on an existing file I get this error:
Detected read/share error (value written: 2 / value read: 1 )Looks like the FileFlush does not cause an update at the second handle.
So this was finally discussed on the Russian forum after an other user reported the same issue.
They will NOT fix it, we have to deal with it. They just propose an (obvious) workaround.
Forum on trading, automated trading systems and testing trading strategies
Slava , 2020.04.24 08:37
I understand the problem you described.
1st Expert Advisor writes a file. It may not close this file, but in this case should call FileFlush
The 2nd Expert Advisor reads the file. It must open the file every time, then close it.
Opening and closing a file is only for the second adviser!
So this was finally discussed on the Russian forum after an other user reported the same issue.
They will NOT fix it, we have to deal with it. They just propose an (obvious) workaround.
Great. Especially in duplex mode where none of them knows who is first or second. This is not really a working workaround, it´s a performance killer, cause you can only deal with it, when the file is permanently opened and closed by all EAs and indicators which access it.
The only true workaround is: Do it with Windows functions and activate DLL.
Great. Especially in duplex mode where none of them knows who is first or second. This is not really a working workaround, it´s a performance killer, cause you can only deal with it, when the file is permanently opened and closed by all EAs and indicators which access it.
The only true workaround is: Do it with Windows functions and activate DLL.

- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
FILE_SHARE_READ and FILE_SHARE_WRITE do not work proper. MQL creates buffers with different contents for the same file.
Please watch the example. It´s one of these "Sometimes bugs". If you cannot provoke the shown output, play around with the lines, add more FILE_SEEKs or change the filename. If you suspect the macro FILE_WRITE_STRING ... it´s ok, I can provoke the error also without it. But I had to play around with the code until the error was shown. Once the error occurs, you will never get rid of it until the filename is changed. This is really not funny.
This is the output, which it should never be, but which is it in almost all cases
It can only be fixed, when the file-handle, which is used for reading, is closed and reopened. In other words, FILE_SHARE_WRITE seems to work, but FILE_SHARE_READ does not.