[Scummvm-devel] File handling revamp

[Max Horn]

Am Di, 29.07.2008, 17:29, schrieb Johannes Schickel:
> On Tuesday 29 July 2008 16:03:10 Max Horn wrote:
>> > Well there's one problem all engine developers have to address when
>> > using FSNode for opening files in directories: case (in-)sensivity.
>> > That blows the client code unnecessarily IMHO.
>>
[...]
>
> Well for engine usage as in Parallaction:
>
> _partDir = _baseDir.getChild(name);
> _aniDir = _partDir.getChild("ani");
> /* ... */
> (engines/parallaction/disc_br.cpp ll106-116)
>
> and
>
> Common::String path(name);
> FilesystemNode node = _talDir.getChild(path);
> if (!node.exists()) {
> 	path += ".tal";
> 	node = _talDir.getChild(path);
> 	if (!node.exists())
> 		errorFileNotFound(_talDir, path);
> }
> (engines/parallacction/disc_br.cpp ll136-143)
>
> 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!

[...]

>>    f.open("foo/bar.dat");
>> or
>>    f.open(FSNode("foo/bar.dat"));
>> or
>>    f.open(FSNode("foo").getChild("bar.dat"));
>> or
>>    f.open("bar.dat", mySearchPaths);
>> or even just
>>    f.open("bar.dat");	// Search in the global list of default seach
>> paths
>
> Little note from my side: Example 3 will of course not be working
> currently, unless 'foo' is an absolute path or in the cwd on some systems.

Noted. The above was not meant to suggest how existing code would work,
but rather how code *should* look, in an "ideal" system. I.e. I am trying
here to figure out how the API should look and behave in the future, to be
most effective for engine authors to use, yet be clean enough to
implement, document and understand. This also holds for all the other code
"examples" below -- they don't work, they just "could" work at some point
in the future.

So yeah, getChild on an illegal note will crash currently. And FSNodes are
not case insensitive :).

> (Known since ages too).

Never saw a report about that.... But that belongs on the "communication"
thread ;)

[...]

>> Depending on the requirements of the client code, each of these code
>> have its merits. Personally, I would think that for client code
>> writers the following are the most important possibilities:
>> 1) f.open("foo/bar.dat");
>> 2) f.open("bar.dat");
>> 3) f.open("bar.dat", mySearchPaths);
>> What is unclear to me is whether the first one should only look under
>> PATH/foo/bar.dat; should look in all search paths for a dir foo with a
>> file bar.dat.
>
> All three examples look like what it should be for the user later on. Of
> course we should have to take care of File::exists etc. too. And I'm
> personally for searching *all* global search pathes in example 1), since
> it would follow the sames rules as example 2) with that.

Fine by me. BTW, this is one of the reasons I wanted to split of DumpFile:
When reading files, we want to search them everywhere. But when writing
files, things are differently. They should end up in a specific location
(e.g. "dumps/", or a "cache" dir for the MT32 emu / theme cache etc.). So
right now my plan is to have no search path support in DumpFile, removing
yet another complexity.


Cheers,
Max