[Scummvm-devel] FilesystemNode specs
max at quendi.de
Wed May 3 02:57:01 CEST 2006
I am sending this to scummvm-devel, as it may concern other porters,
Am 03.05.2006 um 11:19 schrieb Marcus Comstedt:
> Max Horn <max at quendi.de> writes:
>> BTW, it's fine you changed the comment, but since it's going to stay,
>> if I was you I'd remove the "FIXME" part and just turn it into a text
>> that explains why you don't bother to check for the validity of the
> I'll probably make a separate filesystem backend for the DC, in which
> case the comment will go away completely. Originally the posix fs
> backend was a pretty good match since my ISO9660 implementation has
> its (rather limited) API modeled after POSIX, but due to code
> evolution it seems a separate backend is now a better idea.
> In my own backend, I'd like to have different classes for files and
> directories; can I assume that the argument of getChild() will always
> have a trailing slash if it is a child directory you want?
At this point, no. But we could extend the specification accordingly.
But then we should modify at least the POSIX FS implementation (and
better the windows one, too) to enforce this, else it *won't* be
adhered to (not out of malice, but simply because it's very easy to
slip on this).
> Or perhaps
> it would be less opaque to have two methods, getChildFile() and
This is still very new code and we can decide now how we want it. The
two intended main uses for getChild are the following:
1) To replace code like this
File::addDefaultDirectory(_gameDataPath + "ROOMS/");
Clearly, getChildDirectory() could be used here.
2) To allow engines to access files "in the current directory" w/o
having to invoke a full listDir:
if (fileNode.isValid() && fileNode.isFile())
// do fancy things with the file, for example, open it:
File myFile; myFile.open(fileNode);
Clearly, here getChildFile() could be used.
In all other scenarios I can imagine, you know in advance whether you
want to get a file or a directory node. However, what happens if I
try to get the file "00.LFL", but there is a directory with that name
(due to malice or by accident)... Yeah, we don't have to gracefully
handle all and every potential problem thrown us, but we should
*handle* it nevertheless... In this particular case, see the above
example, it asks whether node is valid (exists) and is a file. Of
course we can remove those checks, and instead rely on File::open to
return an error if the node is invalid. That's fine by me, too, but
then we must make sure File::open resp. fopen handle this correctly.
Not really a problem I guess -- it just should be written into the
specs (doxygen comments) of all involved methods.
More information about the Scummvm-devel