The VFS is 0 A.D.'s abstraction of the file system.
It maintains a unique tree representation, combining any mods and folders we "attach" into it.
Any given "virtual path" (VfsPath) is represented by a list of VfsDirectory, and finally a VfsFile.
Example:
"simulation/components/Gate.js" -> VfsDirectory "", has a child VfsDirectory "simulation/", has a child VfsDirectory "components/", which itself has several files inside it, one at the path Gate.js.
To generate this representation, 0 A.D. code "attaches" real directories (RealDirectory) into the VFS, at a given mount point.
For example, mods such as mod or public are loaded at mount point "" (root), screenshots are loaded from the user folder at screenshots/.
Each VfsDirectory keeps a link to a single RealDirectory (currently the latest mounted, see D2781).
To avoid IO slowdowns, a "lazy loading" feature is implemented. When attaching a folder, the VfsDirectory is created/updated, but the actual process of "looking for subdirectories and files, registering them in the VfsDirectory", which is called populate, is deferred until one of two things happen:
- a vfsLookup call is made (i.e. somebody asked for the directory and/or a child of the directory)
- another real directory is attached to the same mount point.
The 2nd case is where things kind of break down -> it's necessary or we would "forget" to populate the original directory, but it also means that in a multi-mod setup (like 0 A.D. is now), the population happens rather early.
The implementation of this lazy-loading is a CAS atomic call in a rather unexplicited manner in VfsAttach. I think it should be removed.
This diff fixes it by actually setting the real-directory right away, which leads to populating right away, but it should really be cleaned up more now that the problem is correctly understood.