[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[52120] scummvm/trunk/common/fs.cpp (and r52121)

[Eugene Sandulenko]

On Mon, 16 Aug 2010 22:56:42 +0200
Johannes Schickel <lordhoto at gmail.com> wrote:
> The real bug here is that FSNode (the ArchiveMember implementation of
> FSDirectory) is not returning the proper name in getName() IMHO. A
> getPath() would have semantics that are unknown to Archive, since an
> Archive is unware of any real path.
I am talking about _internal_ paths inside of Archive. Every
implementation of it and idea of going recursively implies that there
are directories.

> The question is what is a directory?
A thing containing files.

> An Archive object itself?
Yes, if you want to match against "", though I believe that means
nothing today.

> ArchiveMember currently is only aimed at representing files, so it is
> currently not a good idea to use that in listMembers to represent
> directories. Directories have properties like sub-files etc. which are
> all unknown to our Archive API, since it was never designed for that.
Then it is wrong implementation, as currently it is used for games such
as SPY Fox in Hold of Mustard which relies on files being in
subdirectories. That is why I initially introduced
addDirectoryRecursive method which is now replaced by Archive.

> Maybe you also want to tell why you want to list directories?
I need it for the following pseudocode:

  archive->listMatchedMembers(list, "rooms/*");
  foreach it in (list) {
    executeScript(it->getName() + "/default.lua");
  }

It is part of BS2.5 engine and in fact is in game scripts, and I have
no control over it. So if Archive will be decided to not handle
directories at all, I will have to write my own local subclass.


Eugene