OPENFILE() and CLOSEFILE() file corruption

[spacefractal]

This cannot been say enough. its have been happens some times here, im are not sure why. but please allways do auto backup save files, if the first one should been corrupted. Its have been happens in Greedy Mouse and hence got 1 star review due that.

In the recent version, im do uses double file saving now, due im cannot trust glbasic at all in this area.

Recently its have been happens TWICE in Karma Miwa (again today), which is quite annoying. Its look like GLBasic does not close files correctly when CLOSEFILE() is sent, or its "crash" here and then simply just delete the file or corrupt it instead.

That is a high profile bug, and the most annoying, im have no clue why its happens (other than the game was in suspended mode while the game was on, me thinks).

Here is the save file to been used:

Code: (glbasic) [Select]

FUNCTION SaveStrOnce: File$, Base$

LOCAL ok, st$, sc$
ok=OPENFILE(1, File$, 0)
IF ok=FALSE THEN RETURN
LOCAL number=342347
FOREACH item IN MyVar[]
IF item.File$=Base$
FOREACH item2 IN item.VAR[]
number=number+1
st$=URLENCODE$(item.File$)+"|"+URLENCODE$(item2.Name$)+"|"+URLENCODE$(item2.Value$)
sc$=st$
st$=TRIM$(ENCRYPT$("C32(&@3)4"+number+"/&fsd"+HashCrypt$(File$), st$))
LOCAL h$=TRIM$(HashCrypt$(st$))
st$="#"+st$+"#"+h$
WRITESTR 1, st$+"\r\n"
NEXT
ENDIF
NEXT
CLOSEFILE 1
ENDFUNCTION


FUNCTION SaveStrAll: File$, NotSave$=""
LOCAL ok, st$, sc$
ok=OPENFILE(1, File$, 0)
IF ok=FALSE THEN RETURN
LOCAL number=342347
FOREACH item IN MyVar[]
IF (item.File$<>NotSave$ OR NotSave$="") AND item.File$<>"Input" AND item.File$<>"Sprites" AND item.File$<>"Files"
FOREACH item2 IN item.VAR[]
number=number+1
st$=URLENCODE$(item.File$)+"|"+URLENCODE$(item2.Name$)+"|"+URLENCODE$(item2.Value$)
sc$=st$
st$=TRIM$(ENCRYPT$("C32(&@3)4"+number+"/&fsd"+HashCrypt$(File$), st$))
LOCAL h$=TRIM$(HashCrypt$(st$))
st$="#"+st$+"#"+h$
WRITESTR 1, st$+"\r\n"
NEXT
ENDIF
NEXT
CLOSEFILE 1
ENDFUNCTION


[spacefractal]

im allready do that. in Greedy Mouse im save to two files. its some thing very strange on the moment, something, that could been issues in DECRYPT$ and ENCRYPT$, rather than OPENFILE? Something its very strange what it happens.

[spacefractal]

but im are not sure what it happens and is still not. But just to make sure to save a backup file for game progress. Im are still not sure why the file got corruption.

Now im save progress on a level completning in one file, and to a backup file on quit (which seen its that one that might corrupt the file).

My long shot is, OPENFILE shoud fail, if its still not closed (etc you quit while saving, which can happens).

[Ian Price]

I've never seen this happen in any of my apps and nobody has ever reported it. B'lox! saved over 120 elements and Guru Logic saves over 350. I've never had a single complaint about losing their saved data.

Are you sure users aren't exiting the app while it is saving? Is there a reason your save code is so complex? Does it have to be this way?

[MrTAToad]

Dont think that Greedy Mouse is unique in this respect - I've had the same sort of problem with EA's The Simpsons : Tapped Out on the Android a fair few times...

Anything that could interrupt the saving process could cause it - for example, low battery (and automatically shutting the device down) to the user manually doing the same.  Portable devices could be more susceptible (especially if the save file is large) as the data may be trying to access slow media (especially an SD card).

You may think this is a bit of an overkill (and could potentially be slightly complicated) is to do your saving stuff to the device (perhaps optimise even more), and also send the same save data to a web server (not at the same time, of course).

Other possibilities could also include saving the data as binary (and not as text), with possible error correct (for automatic fixing).

The other possibility (and you are going to like this even less), is that the manufacturer has introduced a bug in their system - the other possibility is that there is no space left.  Unfortunately neither of which can be detected, although for the latter you could interface with Java to get the amount of space left for the location of where you are storing the data.

[Moru]

I was reading and writing files of several megabytes many times per week without any corruption but this was of course under windows. While saving, create a checksum of the data you write. After closing, open up the file again and read back recalculating the checksum to make sure it's correct. Don't autosave while the app is turning off, you might not have the processing power to save the whole file before the app gets forced shutdown. I'm not sure how much time you have but I remember reading it somewhere that the time is limited.

[spacefractal]

here its got corrupted some times and some people have even reported after a crash (which was Java relavent issue, not in Glbasic code).

Yes the save rutine is somewhere quite complex, because im uses a tvar string type database, and also using hash and checksum in each variable (to prevent cheating).

The only longshot its got corrupted its extractly quit while saving, and then im got a 0 byte file, and lost all progress. Sometimes its might have save twice.

So im not sure OPENFILE does checking if its allready open or not? Its should fails, if its is.

Now im do have two files that save game progress, one on qiut and another one after level complete.

[Slydog]

A long shot, but does this still happen if you use the GENFILE() command to return a valid file id?
http://www.glbasic.de/xmlhelp.php?lang=en&id=271&action=view

Don't cache the file id results, but get a new id each time you save or read.  Just a thought.