[Scummvm-devel] ATTN Porters: SaveFileManager API Adjustments

[Marcus Comstedt]

Johannes Schickel <lordhoto at scummvm.org> writes:

> This is behavior you suggest for listSavefiles is exactly the reason
> why I looked into this. Our default implementation thought this is a
> good idea and did it. And that is a real problem, because it results
> in discovered save files which can not be loaded.

Huh?  How is that possible?  listSavefiles should only return names
of files which actually exist.  If the file exists it should be
possible to load it, if you use its correct filename (which is the one
returned by listSavefiles).

If there is a file "FnorD.99" and listSavefiles is called with the
glob "fnord.##", then listSavefiles should return "FnorD.99", because
that is the name of the file which matches the glob, and the engine
should pass the name "FnorD.99" to the openForLoading function, becase
that is the save file that was discovered.  If the name of the file is
"FnorD.99" and you call openForLoading with the name "FnorD.99" it
should work regardless of whether the filesystem is case insensitive
or not.


>> B) Never try to create two saves with file names which differ only in
>>     case
>
> Pretty sure, no engine will intentionally do this.

I'm pretty sure they don't actually intend to violate A either.


> Always lowercasing to try to work around case sensitivity is not an
> option as we already figured out.

Performing lowercase _across the board_, as would be the case if it is
done in the backend, is not an option.  It can still be an option for
specific engines, especially new ones.


> The thing is: if you let engines worry about case sensitivity, they
> will need to replicate a very similar behavior like you would need to
> implement in your backend.

But they would know which behaviour they actually need, and not have
to cover hypothetical cases they know won't happen.


> So, how big would the penalty be for your system?

Well, let's try to math it out.  Let's say that reading the file list
and reading a small save takes the same amount of time T.  Let's also
say that you have N saves which match the current target.  To present
the save game dialog, the engine has to call listSavegames once,
and openForLoading N times.  listSavegames only needs to fetch the
list of files, to it takes time T.  openForLoading will open the file,
which internally needs to fetch the file list to get the start block
number, and then the file can be read, so T+T=2T time for that.

So with current (case sensitive) implementation this takes T(2N+1),
which amounts to maybe 5 seconds for a reasonable N.  Incidentally, it
used to take T(2N+100-N) because the engine would war-dial all
possible savegame names, which was horrible of course.  Hence the
existence of listSavegames.

Now, if each call to openForLoading needs to perform an extra file
listing so it can figure out the case before it can call the real open
function, the time for reading the file becomes 3T instead of 2T.  So
the savegame dialog would now need T(3N+1) time to pop up, which is an
increase of approximately 50%.  When it already takes several seconds,
this is pretty bad.


  // Marcus