Storage: File already written with different data

[espruino-discuss]

Posted at 2020-03-18 by user109783

I run a example in STM32F4DISCOVERY board.
It's about Storage.
I copy codes into right-side IDE like this:

var s = require("Storage");
s.write("hwll","ddd");

then I send and save into board.
But it make error like this

Uncaught Error: File already written with different data
at line 1 col 21
s.write("hwll","ddd");

What's wrong with it?

[espruino-discuss]

Posted at 2020-03-18 by @gfwilliams

What you're doing looks fine. What firmware are you using? I know that problem was present on older firmwares.

---

Posted at 2020-03-18 by user109783

I cloned the project from github, and build myself, version is 2v04. I deleted some modules which I don't want in the build file. But Storage module still there.

---

Posted at 2020-03-18 by AkosLukacs

If you had previous firmware, the storage module changed to allow longer file names. Completely erasing flash, or issuing a require("Storage").eraseAll() should fix the issue.

---

Posted at 2020-03-18 by user109783

You are right, Thank you again!

[yerpj]

I just got same error

Uncaught Error: File already written with different data
 at line 134 col 59 in .bootcde
    require("Storage").write("conf.json",JSON.stringify(f));

It happens sporadically. The file conf.json is written once per minute.

My context:
VERSION: "2v25.354",
GIT_COMMIT: "31de06e53",
BOARD: "NRF52832DK",
RAM: 65536, FLASH: 524288, STORAGE: 40960,
SERIAL: "6ab2e4cb-c1f1de34",
CONSOLE: "Serial1",
MODULES: "Flash,Storage,hea" ... "am,http,NetworkJS",
EXPTR: 427800

Seems that when the error appears, it can corrupt the .bootcde file and make the script crash.

Any idea?

edit: in my case, f is a JSON object with a size of around 250 bytes

edit(2): process.memory() returns process.memory() ={ free: 1980, usage: 650, total: 2630, history: 35, gc: 0, gctime: 4.91333007812, blocksize: 13, stackEndAddress: 536927304, stackFree: 7832, flash_start: 0, flash_binary_end: 432544, flash_code_start: 442368, flash_length: 524288 }

[gfwilliams]

Are you using a firmware from more than a week ago? On Friday I found an error that could have caused storage corruption, so it might be it's already fixed

[yerpj]

Yes the firmware is very likely to be older than a week. I just recompiled with 2v26.1. I will let it run for a few hours and let you know of the outcome.

[yerpj]

I have been testing the same script with version 2v26.1 for 5 hours now and everything seems to work fine. At this stage I am confident that the recent bug fix seems to have corrected the problem I was having.
Thank you @gfwilliams for your support!

[yerpj]

Problem seems to be fixed with 2v26

[gfwilliams]

Excellent! Glad I finally managed to find the culprit for the nRF52 issue - looks like the code at fault has been in there for around 7 years, you just had to be very unlucky with the timings of large writes for it to be an issue