Previously file entries in the -ivfsoverlay yaml could map to a file in the external file system (specified via the 'external-contents' property, taking a path), but directories had to list their contents in the form of other file or directory entries (via the 'contents' property, taking an array). Allowing directory entries to map to a directory in the external file system (via the same 'external-contents' property as file entries) makes it possible to present an external directory's contents in a different location and, in combination with the 'fallthrough' option, overlay one directory's contents on top of another.
As an example, with the yaml below:
{ 'roots': [
{
'type': 'directory',
'name': '//root/',
'contents': [
{
'type': 'directory-remap',
'name': 'mappeddir',
'external-contents': '//root/foo/bar'
}
]
}
]}The path 'root/mappeddir/somefile' would map to 'root/foo/bar/somefile' in the external file system. If that file wasn't found in the external file system and the 'fallthrough' configuration option is true, it would fall back to checking for 'root/mappeddir/somefile' in the external file system. This effectively overlays the contents of root/foo/bar/ on top of //root/mappeddir.
Resolves rdar://problem/72485443
I think we should expand on this a bit more to contrast a directory-remapped directory vs a file-remapped directory (for a lack of better term). Specifically, an empty file-remapped directory could be confusing, as it behaves quite differently but looks pretty similar in YAML.
{ 'type': 'file', 'name': <string>, 'external-contents': <path to external file> }{ 'type': 'directory', 'name': <string>, 'contents': [] }Looking at the two, I wonder if there would be any benefit to changing the type in the yaml to match the NameKind.