Use correct count in save data focus compares. Also fix the random data that caused the issue. Also fix time compares.

[xsacha]

Currently save compares use a constant value of 100 to compare through even if there is only 1 actual save game.
The second problem is that the data for the other 99 slots is uninitialised, giving it random data. In the focus compares, this data can appear 'newer', even if it doesn't exist.
When I try to load an old game, I will often (when save dirs are populated) have the issue where it shows me the 'latest' game save which is actually a non-existent save.
saveDataListCount = 100
saveNameListDataCount = 1

Another unrelated issue I discovered was that on QNX, time_t is unsigned and a mktime(0) gives 4294967295 which should be cast so it appears as -1. Some platforms use 64-bit time as well, so I cast this with (s64).

[unknownbrackets]

Hmm.

So, when saving and loading, it runs this:

                saveDataListCount = 0;
                while (saveNameListData[saveDataListCount][0] != 0)
                        saveDataListCount++;

It's true, most games list out "DATA00" all the way to "DATA99".

saveDataListCount is then set to the total number of slots specified by the game.

This way, you are allowed to save in a slot you've never used before. For example, in Crisis Core, you can go to slot 40 and save your game there. I believe this is how it works on a PSP?

But you're probably right, last/oldest/newest might be buggy. But I thought load only showed existing saves anyway?

-[Unknown]

[solarmystic]

@unknownbrackets

I think this is the phenomenon that @xsacha is referring to, the presence of "garbage" latest save files in the load menu when the savedirs are populated beyond a certain number by various games and their associated savedata. Especially if you've tested and played a wide variety of games (50-60+ titles on my count)

I've been trying to find a foolproof way to repro the issue for a long time, and FF III was the game it appeared in most frequesntly. Danganronpa is another one, albeit less frequently.

E.g. In Final Fantasy III:

Scrolling upwards in the list with the dpad eventually reveals your actual save files, after sifting through the garbage savedata:

[xsacha]

@unknownbrackets This only affects 'load'ing games.
Save games will still have 100 slots.

The realcount is added to even if the save dir doesn't exist unless it's a LOAD type.

 if (param->mode == SCE_UTILITY_SAVEDATA_TYPE_LISTLOAD ||
                        param->mode == SCE_UTILITY_SAVEDATA_TYPE_LISTDELETE)
        {
                listEmptyFile = false;
        }

Right now, it still looks through 100 slots even if listEmptyFile is false.

@solarmystic
Yes, indeed it shows a garbage save and you have to scroll up to find real ones.
I get this most frequently on Soul Calibur but it also happens on Final Fantasy and many other games.

This is because the save data count is 100 even if it has only populated data for a single save game!! So you have junk data for the other 99 saves. If any of the junk data has a newer 'modified file date', it appears instead of the real save.

The above image shows me trying to load a save in Soul Calibur. The modified file date of slot #1 is newer than the real save data in slot #0 on Blackberry (just due to memory organisation) so I get this with 100% repro.
However, as the size of the file is 0, it shows 'NEW DATA' instead of the junk save. Attempting to load this junk save will get you stuck on the loading screen with no way of getting out.

[unknownbrackets]

Should we be zeroing some things out so that it doesn't organize it wrong?

This has never happened to me in FF3, and I have a ton of savedata... is there something more to reproducing it?

-[Unknown]

[unknownbrackets]

Well, anyway, I think it should just be using saveNameListDataCount in all those other funcs, but it seems like either way is probably fine.

-[Unknown]

[xsacha]

Yeah I can just change all the other functions to use the right count.

[xsacha]

OK, a few more fixes in now.
I initialised everything to 0 which got rid of the junk data.

Then I was surprised (thought something must be wrong) because my Blackberry still thought that the non-existant saves were 'newer'.
Then I found out QNX uses 32-bit unsigned values for time_t and there are even some platforms that use 64-bit values (different versions of QNX even apparently). The mktime gives -1 which is obviously a very large number and made it think it was newer.

[hrydgard]

Good catch :) Let's merge.