[Scummvm-devel] File handling revamp

[Max Horn]

Am Di, 29.07.2008, 20:13, schrieb peres:
> Here are my laughable 2 cents (especially laughable since I got up to
> write after I had gone to sleep).

Nah, that's just pathetic not laughable *ggg*.

No, seriously, your thoughts are not laughable but rather you raise some
quite sensible points. I am happy that for once a lot of people are
pariticpating in the discussion.


>
>>>
>>> The code suffers from case sensitivty issues on Linux for example. A
>>> user
>>> with the files in uppercase would of course get some file not found
>>> error
>>> messages.
>>
>> OK. So, we should change FSNodes to be case insensitive. Noted!
>
> I don't think changing FSNodes to be case insensitive is a good idea,
> since it is the foundation on which File, DumpFile, ConfigFile and
> SaveFile are built. We have the following situation:
>
> * File: created by a software house, located and read by ScummVM
> * ConfigFile: created by the user (also by ScummVM, but user can change
> it), located and read by ScummVM
> * DumpFile: created by a developer (via ScummVM), located and read by a
> developer
> * SaveFile: created by an engine, located and read by an engine (the same
> engine!)
>
> SaveFile is not interesting since the engine manages all its existence
> (provided the user doesn't mess with it!), but the remaining 3
> incarnations all show the same pattern, that is the creator of the file is
> not the same as its user.

Aye. And it is handled by the savefilemanager, so we don't really need to
concern ourselves with it.

>
> DumpFile is a tool for developers, and it is slightly more interesting.
> Personally, I want my tools to follow my instructions, and I would be very
> annoyed if I couldn't dump 'core', 'Core', 'CORE' in the same directory,
> or worse, to have one overwrite the others. Anyway, it is debatable.

For DumpFile, I agree 100%. It is supposed to be a very simply and stupid
class. No messing around with search paths or file names.

> ConfigFile is more delicate, since it may be created (and modified) by any
> user. We shouldn't get in their way of handling their own file systems,
> because they must be able to choose what it's best for them. I understand
> keeping multiple file systems in directories called 'myconf', "myConf' and
> 'Myconf' is madness, but after all it would be worse to create problems to
> them.

This one is solved by first looking for an exact match (e.g. myConf) and
using that, before falling back to an case insensitive lookup.
Anyway, it's a slightly different matter, I think.

>
> There should be little issues so far, in fact it's the way things are
> managed in ScummVM right now (maybe not for DumpFile, but it's not so
> fundamental).
>
> Our File is the bad guy! I will call it GameFile from now on, as it seems
> a more focused and proper name.

Agreed on both :)

> After all, since DumpFile has been
> created, we are *only* going to use it to read game data, right?

Well, not quite -- there are GUI theme files, GUI font cache, MT-32
instruments data cache, various engine specific data files (sky.cpt, ...),
and maybe others. Oh, and on desktop systems also custom config files. But
except for the cache stuff, all of these are read-only, and not modified
by the user manually.

> GameFile
> would be a thin layer over FSNode, with the responsibility of handling
> case, and it would have a companion called GameDirectory, to aid keeping
> filish and directorish stuff separated.

You mean: FSNode stays as it is, and GameFile is a wrapper / different
layer which makes use of FSNode, but adds such things as locating files
regardless of case; ignoring trailing dots in filenames (as in "GAMEPC"
vs. GAMEPC."; see also common/file.cpp:296) ?


> The root GameDirectory would be returned by a method in OSystem (there
> were plans for getting/setting ConfigFile as well, no?),

I am not sure I understand what the "root GameDirectory" is meant to be
(an object somehow corresponding to the game "path" config entry? if so,
what does it got to do with OSystem ?)

> and then the
> engine would be able to tell it wants it to be case sensitive or not
> (because the engine *knows*). Since every other GameDirectory and GameFile
> would originate from the root, the case [in]sensitiveness can be easily
> propagated.
> In case of a name clash when looking up a GameFile, I dare to say the only
> sensible solution is to explicitly tell the user to fix his/her messy
> directory and error out!

Agreed, I don't really think we have to worry about name clashes, and I
think they will be very very rare anyway.

>
>
> I hope there is something worthy in the middle of all this stuff I wrote
> at 3.13 am.
>

;)

Cheers,
Max