a core bug just raised its ugly head...
In data stores there are version numbers, but obviously only the last digit of the decimal value of this version is used in file names. The version counts upwards to ???
It seems, that datastore version counts up to 65535 (max. unsigned short int). Then a bug happens: The new data is saved correctly, and if the save is not loaded, i.e. the core runs on, all is well.
But if you try to reload from the last save, the datastore is _not_ loaded, even if it exists. Then it is overwritten later (since core thinks, there are no data), and all data are lost.
This problem is not very critical, since you need around 65.000 saves (7.4 years if you save every hour) for this to happen. It can be fixed, if you have a good save: Correct the version numbers manually (datastore.txt, check the numbering of your latest data store save, it should have the last digit of the version. Start the version with 1 again). This seems to work.
To prevent it, simply check in datastore.txt if there are any very high version numbers. You can reset them all, this will prevent the problem.
OWHorus
[Edit: Looked into sources - may have found the problem - not sure]
In the sources the version of each datastore is written to datastore.txt - and read back, if the save is loaded.
Generation of filename.version_index.txt for the datastore save in /ds is done by (unsigned)ver%10.
This works - but I think, if the version is bigger than 65535 (i.e. unsigned short) the version number read back is truncated
to a short unsigned, despite the fact, that in the class DataStoreFile the version numbers are declared unsigned (i.e. long).
The defective save has for one old datastore element the version number 65560.
DataFile
{
Descriptor ::housing
Name housing
Flags 1
Version 65560
OldVersion 65559
}
To this entry two files exist in ds/.. : housing.0.txt and housing.9.txt.
Both files are ok. But whenever I try to load this save, a new housing.x.txt is generated, with size zero.
So I think the problem happens while reading datastore.txt. Every version number bigger than 65535 is truncated by reading it.
Possible fix: While incrementing the version (during each save, if the datastore file is dirty) truncate the version number to unsigned short, and restart with zero, if bigger than 65535. (Or declare the version numbers in class DataStoreFile as unsigned short, would be even better, I think).
OR fix it so, that the config reader can read bigger decimal numbers.
Did not try it - only deduced this from the source and from the behavior!
OWHorus