langfeldt71:
all of the moderators expect these -- as a minimum before they will respond. Many of them will ignore this thread -- until the op has added evidence of their issue.
I can provide the minimal reproducer source, complete per-operation log, and the original/control result matrices. The production EA is not required to reproduce the issue.
langfeldt71:
I am investigating a reproducible MQL5 file-persistence problem in MetaTrader 5 Strategy Tester, terminal/tester build 6182.
I am investigating a reproducible MQL5 file-persistence problem in MetaTrader 5 Strategy Tester, terminal/tester build 6182.
Reproducible by whom ?
No code is provided.
No config.
No settings.
It's NOT reproducible.
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Subject: MetaTrader 5 Build 6182 — FileMove(..., FILE_REWRITE) intermittently returns ERR_CANNOT_OPEN_FILE (5004) when replacing a closed existing file in Strategy Tester
Hello,
I am investigating a reproducible MQL5 file-persistence problem in MetaTrader 5 Strategy Tester, terminal/tester build 6182.
The failure occurs at:
FileMove(temp_file, 0, destination_file, FILE_REWRITE)
The returned value is false , and an immediate GetLastError() after ResetLastError() returns:
5004 — ERR_CANNOT_OPEN_FILE
The important point is that this is occurring when both source and destination are believed to be closed by the MQL program.
I extracted the persistence sequence into a minimal native diagnostic so the trading EA itself is not required to reproduce the behavior.
The normal sequence is:
Create a new temporary file with FileOpen(... FILE_WRITE ...) .
Write the complete payload.
FileFlush() .
FileClose() .
Confirm the temp and destination files exist.
ResetLastError() .
Call FileMove(temp, 0, existing_destination, FILE_REWRITE) .
Capture the return value and GetLastError() immediately.
If successful, reopen/read/verify and close the destination.
Results in the original Strategy Tester runtime location:
Closed temp → new/nonexistent destination: 1024 successes / 0 failures.
Closed temp → existing closed destination with FILE_REWRITE: 1011 successes / 13 failures.
Repeated exact persistence sequence against the same existing destination: 2043 successes / 5 failures.
Same sequence interleaved with the program's normal load/readback helpers: 1013 successes / 11 failures.
Actual persistence helper redirected to harmless probe filenames: 1014 successes / 10 failures.
Total unexplained closed-file replacement failures in that run:
39
Every one returned 5004 immediately from FileMove .
For all 39 failures:
temporary FileOpen failures: 0
temporary write failures: 0
temporary flush failures: 0
post-successful-move readback failures: 0
caller-tracked open MQL file handles at FileMove: 0
source existed before and after the failed call
destination existed before and after the failed call
Deliberately keeping the source or destination open also produces 5004, as expected. However, those deliberate controls are separate from the 39 failures above.
As a location control, the same compiled diagnostic, same inputs and same logical tests were executed from an equal-length user TEMP runtime location.
Result there:
6,145 normal transport cycles / 0 closed-file replacement failures.
I am not claiming this proves a MetaTrader platform defect, because the two runs were performed at different times/locations and therefore cannot completely exclude an external filesystem/security/background-process interaction.
However, the behavior appears inconsistent with the documented FileMove contract, which states that an existing destination can be replaced when FILE_REWRITE is specified.
Could MetaQuotes please clarify:
Is FileMove(source, 0, existing_destination, FILE_REWRITE) expected to be reliable immediately after all MQL handles to both files have been closed?
Does the Strategy Tester maintain any internal/native file handle, scanner or synchronization behavior that can temporarily prevent replacement even after the MQL file handles are closed?
Are there any known Build 6182 issues involving FileMove , FILE_REWRITE , Strategy Tester agent file sandboxes, or intermittent ERR_CANNOT_OPEN_FILE (5004) ?
Is there an officially recommended crash-safe persistence pattern for MQL5 when replacing a state/checkpoint file—for example, whether MetaQuotes recommends versioned generation files rather than replacement of an existing file?
Is there additional diagnostic information we can collect from MQL5 that identifies which internal open involved in FileMove produced error 5004?
I can provide the minimal reproducer source, complete per-operation log, and the original/control result matrices. The production EA is not required to reproduce the issue.
I am specifically trying to distinguish:
expected/documented MQL5 behavior,
a Strategy Tester/build issue,
and an external Windows/filesystem access conflict.
Thank you.