I write my program for importing/exporting files with a card, and I noticed, that sometimes checksums of imported/exported files don't match. I tried to use original import.lua/export.lua and got this problem again.

When I compared some original and corrupted files I had seen that in the corrupted file one random byte is zero.

So, I think that this problem lies somewhere in the mod.

i have notice this too

How big is the original file that is being imported and exported? It might have something to do with max size of packets minecraft is able to send.

so i dont think it related to the max packet size cause of the this issue i made awhile ago (#109) im still playing on a server and still have file corrupting occasional even small ones, like 8kb, i get file corruption sometimes, idk why i never made a issue about this

I might try to re implement the file import/export to fix both these issues if it not already being worked on

correction: forgot this issues stated export had issues and not import issues, so both features are cause issues

I think if it's caused by the size of the packet, we can split it to many parts to send.

This can't be packet sizes for these reasons:

1. This occurs in Single Player too, where there is no packet size limit afaik
2. This happens with small files too, just not as often
3. The bytes that are damaged are not at positions that seem related to MCs 32kB packet size limit
4. This does not happen with my import.py, and most likely doesn't happen with fimexu either.
   This means the Java side, and the network side are fully functional.

This can't be packet sizes for these reasons:

1. This occurs in Single Player too, where there is no packet size limit afaik

2. This happens with small files too, just not as often

3. The bytes that are damaged are not at positions that seem related to MCs 32kB packet size limit

4. This does not happen with my [import.py](https://gist.github.com/ToMe25/87926996d7775cf273b6346ea19ac529), and most likely doesn't happen with `fimexu` either.
   This means the Java side, and the network side are fully functional.

Well, I've compiled and tester Coverett, and can confirm fimexu in fact DOES corrupt files sometimes, and i think export feature does it more often. Micropython implementation, however, is AFAIK ok. But I've noticed that your import.py is much much slower than fimexu, and even significantly slower than lua implementation. So maybe IO interface breaks when used too fast?

I have notices a total of three issues that corrupt the imported data so far.

In #216 I have written about two issues I observed, that are corrupting the imported data.
I have not tried to debug exporting, so I can't say how that fails.

These two issues are

1. cjson.decode replacing seemingly random numbers with zeros, corrupting the file but not the message itself.
2. Sometimes the decoded object still has the correct data, but somehow the file still contains a NUL byte instead.

Neither of these issues can be caused by the OC2 Java side of things, because I know more or less exactly where the data changes from OK to corrupt, and its in the lua code.
fnuecke speculated here that this might be an issue with the sedna VM itself.

The third issue, which I didn't open an issue about, in part because I didn't debug it enough, but mentioned in #215, is that sometimes random bytes in the message string itself get replaces with NUL bytes.
In #216 I wrote that this seems to be caused by a string:sub call, however I can't remember whether this was

1. speculation because that was the only thing I changed in that part of the code, or
2. something I debugged and figured out the string was ok before and not after.

If it was just speculation, this could indeed be an issue caused by the Java side when reading the data too fast, since it is however the rarest of the three issues I think ignoring it for now is fine too.
Note that since this damages the message itself, rather than just the payload data, it can cause random crashes of basically all software using devices.lua#readMessage.