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

[Eugene Sandulenko]

On Mon, 16 Aug 2010 19:55:35 +0200
Max Horn <max at quendi.de> wrote:

> Hi there,
> 
> as a quick reply (I need to look at this closer), let me point out
> that yes, we only want to list files, *not* directories. All of the
> Archive classes is designed around that assumption. If
> FSDirectory::listMembers lists directories, then that is IMO a
> regression, which could have serious consequences.
> 
> Eugene, can you explain what the motivation for your changes was in
> the first place?
OK, as discussed on the IRC, I just reverted it altogether.

Thus, this has to be turned into discussion, so CC'ing -devel.

Here is my problem:

I got game data inside of archive:

  m/foo/text.txt
  m/bar/text.txt
  baz/1.dat
  baz/2.dat

There are 2 ways to access it. One is via ZipArchive class, and another
one is via FSDirectory class, both extending Archive.

I have 3 calls:

  listMembers()
  listMatchingMembers(m/*)
  listMatchingMembers(baz/*.dat)

Now ZipArchive gives me somewhat expected results (since directories
have also entries in the archive). The result below are after getName(),
and all of them apparently contain correct pointers to ArchiveMember
instances:

  listMembers() -> [ m/, m/foo/, m/foo/text.txt, m/bar/,
  m/bar/text.txt, baz/, baz/1.dat, baz/2.dat] (8 elements)

  listMatchingMembers(m/*) -> [m/foo/, m/foo/text.txt, m/bar/,
  m/bar/text.txt] (4 elements)

  listMatchingMembers(baz/*.dat) -> [baz/1.dat, baz/2.dat]

Additionally I can check result of second call for presence of '/' to
distinguish directories (I know it's a hack).

But FSDirectory archive gives somewhat inconsistent results, and
moreover, they're weird for the first call and completely wrong for
the second call:

  listMembers() -> [ text.txt, text.txt, 1.dat, 2.dat] (4 elements)

  listMatchingMembers(m/*) -> [text.txt, text.txt] (2 elements)

  listMatchingMembers(baz/*.dat) -> [1.dat, 2.dat]

As you see, first 2 calls pretend like there are 2 copies of same file,
and there is no way to distinguish them, information on their original
position within the Archive is lost.

Another problem is that there is no way to enlist directories, thus
approach with second call fails for me.

Thus, there are 2 problems:
  o (actually a bug). Add way of determining relative path within
    Archive, probably by introducing getPath() same as in FSNode
  o Add way of handling directories, probably by adding third optional
    argument to list functions which will be a bit map of flags like
    (Common::FSFiles | Common::FSDirectories)


Eugene