[Scummvm-devel] ATTN Porters: SaveFileManager API Adjustments

[Marcus Comstedt]

Johannes Schickel <lordhoto at scummvm.org> writes:

> Basically, it means that you can access save files (and other engine
> written files) without worrying about case issues on the underlying
> hardware.

I never had to worry about it before.  The worry starts here...


> As you already discovered this gets problematic when you are on a case
> sensitive file-system and there are conflicting files.

Yes, we are introducing these problems by considering them
"conflicting".  There was no problem with them before, because there
was no "conflict".


>> That openForSaving("foo") should remove "Foo" and "FOO" if they exist?
>
> I wouldn't necessarily make an open call remove files.

But if it doesn't remove them the number of "conflicts" increase.
If it later does openForLoading("foo") it might get one of the other
files.


> Casing in target names is one possibility where different cases can
> originate from. We have (semi) case insensitive target name handling,
> i.e. the case of the target doesn't matter when you run
> games.

I assume you mean when the user inputs a target name on the command
line?  That's never going to happen on the Dreamcast.


> Synching files between devices and/or manually inserting save files
> (from bug reports etc.) is another source for different cases.

Copying a file between memory cards on the Dreamcast preserves the
filename verbatim.  There is no UI to rename a file.  If you have a
Nexus card that allows you to extract files from the card to other
systems, you will get the in the form of VMI files, which also
preserve the filename verbatim (the filename of the VMI file itself is
irrelevant).


> Last but not least, all other engine facing high level file APIs are
> case insensitive, i.e. file opening etc., this change makes
> SaveFileManager fit in.

Ok, I don't want to sound negative here, but I don't really fancy
adding slow and complicated code to all savefile operations to make an
API "fit in".  We have separate APIs for separate things because they
have different requirements (from both engine and platform sides);
adding things which are not based in a technical requirement (and
might actually counteract other requirements) to make the savefiles
"fit in" with other files seems counterproductive.  Savegames are a
separate API because, on some platforms at least, they do _not_ "fit
in" with other files, and may in fact be something completely
different from other files.


> This is especially important because some
> engines use SaveFileManager to write additional files where file names
> come from original game data which were developed on case insensitive
> file systems (thus might not care about it).

In this case a facility to normalize the filename before using it as a
savegame name would seem appropriate.


> They could of course
> worry about providing consistent file names but I went in favor of
> having a consistent API.

Each API should be internally consistent, but if there are technical
reasons for API 1 to do something differently from API 2, I think that
is more important than cross-API consistency.


  // Marcus