RedirectingFileSystem has grown significantly over time. When it was
added it simply performed a path remapping and then used that path in
the filesystem it was passed (ExternalFS). The functionality provided
by -ivfsoverlay was handled by OverlayFileSystem, which would run
operations on the contained filesystems in reverse order.
Since then, "fallthrough" and "redirecting-with" options were added to
the overlay YAML format. As part of these changes, OverlayFileSystem
stopped being used in the handling of -ivfsoverlay and this was
instead handled by nesting RedirectingFileSystem together. The
right-most overlay would use the next-to-the-left
RedirectingFileSystem as its external filesystem, etc.
This allowed:
- Overlay paths to be dependent on previous -ivfsoverlay, ie. a second -ivfsoverlay could specify a virtual path for its overlay if that path is in the first overlay.
- Paths from one overlay to affect those in an earlier, ie. if the right-most overlay specified a mapping from A -> B and the left-most a mapping from B -> C, A could now map to C.
- The real filesystem to be skipped, ie. all specified paths have to be contained in an overlay (which would still map to the real filesystem).
(1) and (3) are now implemented by getVFSFromYAMLs using the
OverlayFileSystem (D121425), which allows removing the
redirecting-with handling from RedirectingFileSystem entirely. With
that removal RedirectingFileSystem is now back to only performing a
path remapping and using that path in the ExternalFS. (2) will no
longer be possible, but this also makes overlays *much* simpler to
reason about.
Depends on D121425