As discovered with elexis on IRC today (2019-09-02)The VFS is 0 A.D.'s abstraction of the file system.
It maintains a unique tree representation, combining any mods can overwrite config filesand folders we "attach" into it.
Any given "virtual path" (VfsPath) is represented by a list of VfsDirectory, including default.cfg.and finally a VfsFile.
Example:
This seems wrong"simulation/components/Gate.js" -> VfsDirectory `""`, because there are plenty of commhas a child VfsDirectory `"simulation/"`, has a child VfsDirectory `"components saying this should be impossible (see e.g./", which itself has several files inside it, GameSetup.cpp:L461)one at the path `Gate.js`.
I've looked around a lot...To generate this representation, 0 A.D. code "attaches" real directories (`RealDirectory`) into the VFS, This is a bit nebulous.at a given mount point.
For example, This code changed quite a bit over the yearsmods such as `mod` or `public` are loaded at mount point `""` (root), but it seems as far as I can tell that it hasn't worked properly foscreenshots are loaded from the user folder at least //years//`screenshots/`.
However, vfs_attack does something weird: it first popuEach VfsDirectory keeps a link to a single RealDirectory (currently the lates a directoryt mounted, then sets its 'real directory' counterpartsee D2781).
It would seem much more logical to do the opposite.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), It comes right away from rP6333,the population happens rather early.
The implementation of this lazy-loading is a CAS atomic call in a rather unexplicited manner in VfsAttach. and it seems like the ordering was perhaps a mistake?I think it should be removed.
This seems to do the correct thing anyways and mods aren't brokendiff 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.