[VFS] Simplify RedirectingFileSystem to perform mapping only

[bnbarham]

Summary

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:

1. 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.
2. 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.
3. 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

[bnbarham]

Noticed there's a ::assign on SmallVectorImpl, use that instead of clear + append.

[bnbarham]

Ah, I should only be depending on the one rather than multiple. I'll fix that up soon (and for the following as well). That does make more sense, not sure why I thought it would need all of them!

[bnbarham]

Update to single review dependency

[dexonsmith]

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).

FileSystem also had a get/set added for the current working directory
to allow for filesystem-specific CWD rather than a process-wide CWD,
further complicating the RedirectingFileSystem implementation.

It's not clear from the description what the plan is for the RedirectingFileSystem's CWD. It sounds like you're suggesting dropping it. If so, what happens if the redirecting filesystem remaps things to a new directory /new/dir that doesn't exist in the underlying filesystem, and the client calls cd /new/dir?

This change reverts RedirectingFileSystem to a single responsibility -
mapping paths and passing that path to the underlying filesystem.

I'm not clear about two things:

• What is "the underlying filesystem"?
• What does RedirectingFileSystem return for something not explicitly listed in the .yaml?

A
later change implements (1) and (3) through the OverlayFileSystem. (2)
is no longer possible, which fixes llvm-project#53306 as a side-effect.

Sorry if I missed a discussions somewhere, but I'm not sure I fully understand the plan for landing these changes. It sounds as if this is going to land, regressing (1) and (3), and then we'll add back (1) and (3) later; is that the plan? That doesn't quite seem right; is there another way to sequence the changes to avoid temporary regressions in tree? (If not, then they probably need to land together.)

[bnbarham]

In D121424#3376299, @dexonsmith wrote:

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).

FileSystem also had a get/set added for the current working directory
to allow for filesystem-specific CWD rather than a process-wide CWD,
further complicating the RedirectingFileSystem implementation.

It's not clear from the description what the plan is for the RedirectingFileSystem's CWD. It sounds like you're suggesting dropping it. If so, what happens if the redirecting filesystem remaps things to a new directory /new/dir that doesn't exist in the underlying filesystem, and the client calls cd /new/dir?

Sorry, I was only trying to give some history here. Adding CWD in caused various complications in RedirectingFileSystem due to the added nesting, ie. what path do we pass to the next FS? Hence all the mess with trying to map back to the original path depending on whether use external names is set, but still passing down the canonical name, etc. I'm certainly not suggesting we remove it, it's much easier to reason about with the simplified RedirectinFileSystem.

This change reverts RedirectingFileSystem to a single responsibility -
mapping paths and passing that path to the underlying filesystem.

I'm not clear about two things:

• What is "the underlying filesystem"?
• What does RedirectingFileSystem return for something not explicitly listed in the .yaml?

1. I've been using "external" and "underlying" interchangeably. But I mean ExternalFS, ie. the FS that's passed into RedirectingFileSystem.
2. It returns no_such_file_or_directory, as it once did. If we want an overlay, we should use OverlayFileSystem. Most of this commit message is trying to explain how we got to where we are today in order to provide some context.

A
later change implements (1) and (3) through the OverlayFileSystem. (2)
is no longer possible, which fixes llvm-project#53306 as a side-effect.

Sorry if I missed a discussions somewhere, but I'm not sure I fully understand the plan for landing these changes. It sounds as if this is going to land, regressing (1) and (3), and then we'll add back (1) and (3) later; is that the plan? That doesn't quite seem right; is there another way to sequence the changes to avoid temporary regressions in tree? (If not, then they probably need to land together.)

The plan is to land them together. I just split them to make it easier to review (ie. smaller chunks). Perhaps this has only just added to the confusion.

To be clear:

• D121421 and D121423 and both be landed separately
• D121424, D121425, and D121426 all need to be landed together. I don't see a way to split them up to avoid that, but if you do please let me know.

[dexonsmith]

In D121424#3376321, @bnbarham wrote:

Sorry, I was only trying to give some history here. Adding CWD in caused various complications in RedirectingFileSystem due to the added nesting, ie. what path do we pass to the next FS? Hence all the mess with trying to map back to the original path depending on whether use external names is set, but still passing down the canonical name, etc. I'm certainly not suggesting we remove it, it's much easier to reason about with the simplified RedirectinFileSystem.

Great; I feel like we need the CWD there; the history was useful, I just took the wrong conclusion overall :).

This change reverts RedirectingFileSystem to a single responsibility -
mapping paths and passing that path to the underlying filesystem.

I'm not clear about two things:

• What is "the underlying filesystem"?
• What does RedirectingFileSystem return for something not explicitly listed in the .yaml?

1. I've been using "external" and "underlying" interchangeably. But I mean ExternalFS, ie. the FS that's passed into RedirectingFileSystem.

Either one would have felt ambiguous to me, because I was wondering if you were referring to the sys::fs filesystem and they both kind of point there! Thanks for clarifying.

2. It returns no_such_file_or_directory, as it once did. If we want an overlay, we should use OverlayFileSystem. Most of this commit message is trying to explain how we got to where we are today in order to provide some context.

Okay, makes sense.

The plan is to land them together. I just split them to make it easier to review (ie. smaller chunks). Perhaps this has only just added to the confusion.

Got it!

To be clear:

• D121421 and D121423 and both be landed separately
• D121424, D121425, and D121426 all need to be landed together. I don't see a way to split them up to avoid that, but if you do please let me know.

Got it; I suggest editing each description to make that super clear in those situations ("these will be landed at the same time, split up only for review convenience").

In this case:

• I think there might be a way to re-sequence D121425 ahead of this commit.
  • The new API can be added and unit tested without deleting features from RedirectingFS.
  • There may be some tests that fail until this commit lands; you can either check for the temporary wrong behaviour and fix them in this commit, or shift those tests entirely to this commit if it's too confusing. But it'll help to see what tests suddenly start passing related to the new API.
• Maybe this commit could be made runtime-configurable (OverlayFS constructor, off-by-default, only used in the new API to start, then the old behaviour removed later), to land it ahead of D121426? Maybe that's too complicated; just pointing out the flexibility.
  • Else, I'd suggest merging D121426 with this one. The changes don't touch the same files and it's not a massive patch so I don't think it'll confuse the review much.

[bnbarham]

In D121424#3376381, @dexonsmith wrote:

In this case:

• I think there might be a way to re-sequence D121425 ahead of this commit.
  • The new API can be added and unit tested without deleting features from RedirectingFS.
  • There may be some tests that fail until this commit lands; you can either check for the temporary wrong behaviour and fix them in this commit, or shift those tests entirely to this commit if it's too confusing. But it'll help to see what tests suddenly start passing related to the new API.
• Maybe this commit could be made runtime-configurable (OverlayFS constructor, off-by-default, only used in the new API to start, then the old behaviour removed later), to land it ahead of D121426? Maybe that's too complicated; just pointing out the flexibility.
  • Else, I'd suggest merging D121426 with this one. The changes don't touch the same files and it's not a massive patch so I don't think it'll confuse the review much.

Landing D121425 before this one is definitely *possible*, but I'd really rather this change be atomic - neither really make sense on their own (IMO). The last option you listed said "merging D121426 with this one", but that one is basically just API updates and a few test fixes for the new behavior. Did you mean with D121425 or just all of them together?

[dexonsmith]

In D121424#3376387, @bnbarham wrote:

In D121424#3376381, @dexonsmith wrote:

In this case:

• I think there might be a way to re-sequence D121425 ahead of this commit.
  • The new API can be added and unit tested without deleting features from RedirectingFS.
  • There may be some tests that fail until this commit lands; you can either check for the temporary wrong behaviour and fix them in this commit, or shift those tests entirely to this commit if it's too confusing. But it'll help to see what tests suddenly start passing related to the new API.
• Maybe this commit could be made runtime-configurable (OverlayFS constructor, off-by-default, only used in the new API to start, then the old behaviour removed later), to land it ahead of D121426? Maybe that's too complicated; just pointing out the flexibility.
  • Else, I'd suggest merging D121426 with this one. The changes don't touch the same files and it's not a massive patch so I don't think it'll confuse the review much.

Landing D121425 before this one is definitely *possible*, but I'd really rather this change be atomic - neither really make sense on their own (IMO).

Can you explain more why you don't think it's a good idea in this case?

For complicated changes, it's not uncommon to add the new API (with tests for it), and then do adoption later.

Actually, I wonder if you could even just land these as three separate commits by doing D121424 last:

• D121425: add new API (causes any created RedirectingFS to be created with these options turned off)
• D121426: change clang to use it
• D121424: remove now-unneeded RedirectingFS code and add tests proving that A->B->C case no longer works

That'd be the usual incremental flow, I think. It also gives out-of-tree clients a good commit window to adopt the new API:

• Temporarily revert D121424 on out-of-tree branch to allow merging main.
• Update out-of-tree code to use the new API.
• Reapply D121424 to match main again.

This also has the major benefit of making post-commit review (e.g., reading git log -u) easier to manage.

Maybe it's not worth it here -- maybe it's a lot of work to make these separately-landable and maybe there aren't (known) external uses of RedirectingFS -- but naïvely, based on seeing three Phab reviews and having a better understanding now of what's in each, it seems like it might not be hard to keep them split?

(If there's some temporary regression to worry about, it's better to unify them, but otherwise separate commits would be preferred I think.)

The last option you listed said "merging D121426 with this one", but that one is basically just API updates and a few test fixes for the new behavior. Did you mean with D121425 or just all of them together?

I meant D121425, then D121424 + D121426, because I assumed those last two were intrinsically linked, but maybe they aren't?

[bnbarham]

In D121424#3376440, @dexonsmith wrote:

Can you explain more why you don't think it's a good idea in this case?

For complicated changes, it's not uncommon to add the new API (with tests for it), and then do adoption later.

Actually, I wonder if you could even just land these as three separate commits by doing D121424 last:

• D121425: add new API (causes any created RedirectingFS to be created with these options turned off)
• D121426: change clang to use it
• D121424: remove now-unneeded RedirectingFS code and add tests proving that A->B->C case no longer works

My thinking was that the state after D121425 + D121426 would be such that the redirecting-with options are implemented in both OverlayFS and RedirectingFS, which I was worried would lead to some confusion if we end up needing to revert/looking at history later/etc. I'd also need to split the parsing changes out of this patch, move into D121425, and then add a bit extra to it to still set redirecting-with on RedirectingFS.

Perhaps that isn't as bad as I was imagining though. I'm a little worried it's just Friday night and I'm not thinking this through clearly, so I'll give it the weekend and try it on Monday if I don't think of anything.

add tests proving that A->B->C case no longer works

Are you asking for a test that manually nests RedirectingFileSystem and checks that this case doesn't work? Or just the existing TEST(VFSFromYAMLsTest, NotTransitive) test in D121425? For RedirectingFileSystem all we really want to check is that ExternalFS isn't used as a fallback, which I believe is already tested in the various VFSFromYAMLTest cases. That actually brings me to something I was meaning to bring up...

One thing that I haven't gotten to in these patches is to fix up the VFS tests in general - I only started laying the groundwork for them. We currently have a whole bunch of VFSFromYAMLTest cases that should probably be split up into testing OverlayFS, RedirectingFS, and then the actual getVFSFromYAML(s) API itself. My guess is that ended up getting mixed in together because RedirectingFS became the implementation of -ivfsoverlay and thus getVFSFromYAML *was* RedirectingFileSystem.

I almost did that in this patch, but thought that it would make it more difficult to review (since other than the A -> B -> C chaining, there shouldn't be any functional changes from the -ivfsoverlay perspective). I would like to do that as a follow up though if that makes sense to you.

[dexonsmith]

In D121424#3376840, @bnbarham wrote:

My thinking was that the state after D121425 + D121426 would be such that the redirecting-with options are implemented in both OverlayFS and RedirectingFS, which I was worried would lead to some confusion if we end up needing to revert/looking at history later/etc. I'd also need to split the parsing changes out of this patch, move into D121425, and then add a bit extra to it to still set redirecting-with on RedirectingFS.

Perhaps that isn't as bad as I was imagining though. I'm a little worried it's just Friday night and I'm not thinking this through clearly, so I'll give it the weekend and try it on Monday if I don't think of anything.

Doesn't sound too bad to me, but let me know what you think. In the first commit adding the new API you can add FIXME/TODOs to the old APIs indicating that the functionality is going away to make it clear what the plan is.

One major benefit is that if there is another client (besides clang), and you need to temporarily revert the "delete the old API patch", it's much less revert-churn that reverting the whole shebang (also, it doesn't block forward progress in clang).

add tests proving that A->B->C case no longer works

Are you asking for a test that manually nests RedirectingFileSystem and checks that this case doesn't work? Or just the existing TEST(VFSFromYAMLsTest, NotTransitive) test in D121425? For RedirectingFileSystem all we really want to check is that ExternalFS isn't used as a fallback, which I believe is already tested in the various VFSFromYAMLTest cases. That actually brings me to something I was meaning to bring up...

One thing that I haven't gotten to in these patches is to fix up the VFS tests in general - I only started laying the groundwork for them. We currently have a whole bunch of VFSFromYAMLTest cases that should probably be split up into testing OverlayFS, RedirectingFS, and then the actual getVFSFromYAML(s) API itself. My guess is that ended up getting mixed in together because RedirectingFS became the implementation of -ivfsoverlay and thus getVFSFromYAML *was* RedirectingFileSystem.

I almost did that in this patch, but thought that it would make it more difficult to review (since other than the A -> B -> C chaining, there shouldn't be any functional changes from the -ivfsoverlay perspective). I would like to do that as a follow up though if that makes sense to you.

One historical reason is that RedirectingFileSystem wasn't previously exposed in a header. Would be great to get this cleaned up!

[bnbarham]

Re-order to be after D121425

[bnbarham]

Blocked on the dependents

llvm/include/llvm/Support/VirtualFileSystem.h

 /// FIXME: 'use-external-name' causes behaviour that's inconsistent with how
 /// "real" filesystems behave. Maybe there should be a separate channel for
 /// this information.
 class RedirectingFileSystem : public vfs::FileSystem {
 public:
   enum EntryKind { EK_Directory, EK_DirectoryRemap, EK_File };
   enum NameKind { NK_NotSet, NK_External, NK_Virtual };
 
-  // TODO: Simplify RedirectingFileSystem to remove redirection completely.
-  // Remove RedirectKind, Redirection, and all non-redirect-only paths. Require
-  // any old uses to move to using OverlayFileSystem instead (see the new
-  // getVFSFromYAMLs API).
-
-  /// The type of redirection to perform.
-  enum class RedirectKind {
-    /// Lookup the redirected path first (ie. the one specified in
-    /// 'external-contents') and if that fails "fallthrough" to a lookup of the
-    /// originally provided path.
-    Fallthrough,
-    /// Lookup the provided path first and if that fails, "fallback" to a
-    /// lookup of the redirected path.
-    Fallback,
-    /// Only lookup the redirected path, do not lookup the originally provided
-    /// path.
-    RedirectOnly
-  };
-
   /// A single file or directory in the VFS.
   class Entry {
     EntryKind Kind;
     std::string Name;
 
   public:
     Entry(EntryKind K, StringRef Name) : Kind(K), Name(Name) {}
     virtual ~Entry() = default;
private:
   ///
   /// Currently, case-insensitive matching only works correctly with ASCII.
   bool CaseSensitive = is_style_posix(sys::path::Style::native);
 
   /// Whether to use to use the value of 'external-contents' for the
   /// names of files.  This global value is overridable on a per-file basis.
   bool UseExternalNames = true;
 
-  /// Determines the lookups to perform, as well as their order. See
-  /// \c RedirectKind for details.
-  RedirectKind Redirection = RedirectKind::Fallthrough;
   /// @}
 
   RedirectingFileSystem(IntrusiveRefCntPtr<FileSystem> ExternalFS);
 
   /// Looks up the path <tt>[Start, End)</tt> in \p From, possibly recursing
   /// into the contents of \p From if it is a directory. Returns a LookupResult
   /// giving the matched entry and, if that entry is a FileEntry or
   /// DirectoryRemapEntry, the path it redirects to in the external file system.
   ErrorOr<LookupResult> lookupPathImpl(llvm::sys::path::const_iterator Start,
                                        llvm::sys::path::const_iterator End,
                                        Entry *From) const;
 
-  /// Get the status for a path with the provided \c LookupResult.
-  ErrorOr<Status> status(const Twine &CanonicalPath, const Twine &OriginalPath,
-                         const LookupResult &Result);
-
 public:
   /// Looks up \p Path in \c Roots and returns a LookupResult giving the
   /// matched entry and, if the entry was a FileEntry or DirectoryRemapEntry,
   /// the path it redirects to in the external file system.
-  ErrorOr<LookupResult> lookupPath(StringRef Path) const;
+  ErrorOr<LookupResult> lookupPath(StringRef CanonicalPath) const;
 
-  /// Parses \p Buffer, which is expected to be in YAML format and
-  /// returns a virtual file system representing its contents.
+  /// Parses \p Buffer, which is expected to be in the YAML format described
+  /// in \c RedirectingFileSystem and returns a virtual file system
+  /// representing its contents.
+  ///
+  /// \see getVFSFromYAMLs
   static std::unique_ptr<RedirectingFileSystem>
   create(std::unique_ptr<MemoryBuffer> Buffer,
          SourceMgr::DiagHandlerTy DiagHandler, StringRef YAMLFilePath,
          void *DiagContext, IntrusiveRefCntPtr<FileSystem> ExternalFS);
 
   /// Redirect each of the remapped files from first to second.
   static std::unique_ptr<RedirectingFileSystem>
   create(ArrayRef<std::pair<std::string, std::string>> RemappedFiles,
public:
   std::error_code setCurrentWorkingDirectory(const Twine &Path) override;
 
   std::error_code isLocal(const Twine &Path, bool &Result) override;
 
   std::error_code makeAbsolute(SmallVectorImpl<char> &Path) const override;
 
   directory_iterator dir_begin(const Twine &Dir, std::error_code &EC) override;
 
-  /// Sets the redirection kind to \c Fallthrough if true or \c RedirectOnly
-  /// otherwise. Will removed in the future, use \c setRedirection instead.
-  void setFallthrough(bool Fallthrough);
-
-  void setRedirection(RedirectingFileSystem::RedirectKind Kind);
-
   std::vector<llvm::StringRef> getRoots() const;
 
   void printEntry(raw_ostream &OS, Entry *E, unsigned IndentLevel = 0) const;
 
 protected:
   void printImpl(raw_ostream &OS, PrintType Type,
                  unsigned IndentLevel) const override;
 };

llvm/lib/Support/VirtualFileSystem.cpp

 
 } // namespace vfs
 } // namespace llvm
 
 //===-----------------------------------------------------------------------===/
 // RedirectingFileSystem implementation
 //===-----------------------------------------------------------------------===/
 
-namespace {
-
 static llvm::sys::path::Style getExistingStyle(llvm::StringRef Path) {
   // Detect the path style in use by checking the first separator.
   llvm::sys::path::Style style = llvm::sys::path::Style::native;
   const size_t n = Path.find_first_of("/\\");
   // Can't distinguish between posix and windows_slash here.
   if (n != static_cast<size_t>(-1))
     style = (Path[n] == '/') ? llvm::sys::path::Style::posix
                              : llvm::sys::path::Style::windows_backslash;
   return style;
 }
 
 /// Removes leading "./" as well as path components like ".." and ".".
 static llvm::SmallString<256> canonicalize(llvm::StringRef Path) {
   // First detect the path style in use by checking the first separator.
   llvm::sys::path::Style style = getExistingStyle(Path);
 
   // Now remove the dots.  Explicitly specifying the path style prevents the
   // direction of the slashes from changing.
   llvm::SmallString<256> result =
       llvm::sys::path::remove_leading_dotslash(Path, style);
   llvm::sys::path::remove_dots(result, /*remove_dot_dot=*/true, style);
   return result;
 }
 
-/// Whether the error and entry specify a file/directory that was not found.
-static bool isFileNotFound(std::error_code EC,
-                           RedirectingFileSystem::Entry *E = nullptr) {
-  if (E && !isa<RedirectingFileSystem::DirectoryRemapEntry>(E))
-    return false;
-  return EC == llvm::errc::no_such_file_or_directory;
-}
-
-} // anonymous namespace
-
-
 RedirectingFileSystem::RedirectingFileSystem(IntrusiveRefCntPtr<FileSystem> FS)
     : ExternalFS(std::move(FS)) {
   if (ExternalFS)
     if (auto ExternalWorkingDirectory =
             ExternalFS->getCurrentWorkingDirectory()) {
       WorkingDirectory = *ExternalWorkingDirectory;
     }
 }

 
 llvm::ErrorOr<std::string>
 RedirectingFileSystem::getCurrentWorkingDirectory() const {
   return WorkingDirectory;
 }
 
 std::error_code
 RedirectingFileSystem::setCurrentWorkingDirectory(const Twine &Path) {
-  // Don't change the working directory if the path doesn't exist.
-  if (!exists(Path))
-    return errc::no_such_file_or_directory;
-
   SmallString<128> AbsolutePath;
   Path.toVector(AbsolutePath);
   if (std::error_code EC = makeAbsolute(AbsolutePath))
     return EC;
+
+  // Don't change the working directory if the path doesn't exist.
+  if (!exists(AbsolutePath))
+    return errc::no_such_file_or_directory;
+
   WorkingDirectory = std::string(AbsolutePath.str());
   return {};
 }
 
 std::error_code RedirectingFileSystem::isLocal(const Twine &Path_,
                                                bool &Result) {
   SmallString<256> Path;
   Path_.toVector(Path);
 
   if (std::error_code EC = makeCanonical(Path))
-    return {};
+    return EC;
 
   return ExternalFS->isLocal(Path, Result);
 }
 
 std::error_code RedirectingFileSystem::makeAbsolute(SmallVectorImpl<char> &Path) const {
   // is_absolute(..., Style::windows_*) accepts paths with both slash types.
   if (llvm::sys::path::is_absolute(Path, llvm::sys::path::Style::posix) ||
       llvm::sys::path::is_absolute(Path,
std::error_code RedirectingFileSystem::makeAbsolute(SmallVectorImpl<char> &Path) const {
   Result.append(Path.data(), Path.size());
   Path.assign(Result.begin(), Result.end());
 
   return {};
 }
 
 directory_iterator RedirectingFileSystem::dir_begin(const Twine &Dir,
                                                     std::error_code &EC) {
-  SmallString<256> Path;
-  Dir.toVector(Path);
-
-  EC = makeCanonical(Path);
+  SmallString<256> CanonicalPath;
+  Dir.toVector(CanonicalPath);
+  EC = makeCanonical(CanonicalPath);
   if (EC)
     return {};
 
-  ErrorOr<RedirectingFileSystem::LookupResult> Result = lookupPath(Path);
+  ErrorOr<RedirectingFileSystem::LookupResult> Result =
+      lookupPath(CanonicalPath);
   if (!Result) {
-    if (Redirection != RedirectKind::RedirectOnly &&
-        isFileNotFound(Result.getError()))
-      return ExternalFS->dir_begin(Path, EC);
-
     EC = Result.getError();
     return {};
   }
 
-  // Use status to make sure the path exists and refers to a directory.
-  ErrorOr<Status> S = status(Path, Dir, *Result);
-  if (!S) {
-    if (Redirection != RedirectKind::RedirectOnly &&
-        isFileNotFound(S.getError(), Result->E))
-      return ExternalFS->dir_begin(Dir, EC);
+  // Create the appropriate directory iterator based on whether we found a
+  // DirectoryRemapEntry or DirectoryEntry.
+  Optional<StringRef> ExtRedirect = Result->getExternalRedirect();
+  if (!ExtRedirect) {
+    // DirectoryEntry - just make an iterator for it
+    auto DE = cast<DirectoryEntry>(Result->E);
+    return directory_iterator(std::make_shared<RedirectingFSDirIterImpl>(
+        CanonicalPath, DE->contents_begin(), DE->contents_end(), EC));
+  }
 
+  // Have a DirectoryRemapEntry - need to check that the external directory
+  // actually exists and then possibly remap names to the virtual path depending
+  // on 'use-external-names'.
+  ErrorOr<Status> S = ExternalFS->status(*ExtRedirect);
+  if (!S) {
     EC = S.getError();
     return {};
   }
-
   if (!S->isDirectory()) {
     EC = errc::not_a_directory;
     return {};
   }
 
-  // Create the appropriate directory iterator based on whether we found a
-  // DirectoryRemapEntry or DirectoryEntry.
-  directory_iterator RedirectIter;
-  std::error_code RedirectEC;
-  if (auto ExtRedirect = Result->getExternalRedirect()) {
-    auto RE = cast<RedirectingFileSystem::RemapEntry>(Result->E);
-    RedirectIter = ExternalFS->dir_begin(*ExtRedirect, RedirectEC);
-
-    if (!RE->useExternalName(UseExternalNames)) {
-      // Update the paths in the results to use the virtual directory's path.
-      RedirectIter =
-          directory_iterator(std::make_shared<RedirectingFSDirRemapIterImpl>(
-              std::string(Path), RedirectIter));
-    }
-  } else {
-    auto DE = cast<DirectoryEntry>(Result->E);
-    RedirectIter =
-        directory_iterator(std::make_shared<RedirectingFSDirIterImpl>(
-            Path, DE->contents_begin(), DE->contents_end(), RedirectEC));
-  }
-
-  if (RedirectEC) {
-    if (RedirectEC != errc::no_such_file_or_directory) {
-      EC = RedirectEC;
-      return {};
-    }
-    RedirectIter = {};
-  }
-
-  if (Redirection == RedirectKind::RedirectOnly) {
-    EC = RedirectEC;
-    return RedirectIter;
-  }
+  directory_iterator RedirectIter = ExternalFS->dir_begin(*ExtRedirect, EC);
+            std::string(CanonicalPath), RedirectIter));
 
-  std::error_code ExternalEC;
-  directory_iterator ExternalIter = ExternalFS->dir_begin(Path, ExternalEC);
-  if (ExternalEC) {
-    if (ExternalEC != errc::no_such_file_or_directory) {
-      EC = ExternalEC;
-      return {};
-    }
-    ExternalIter = {};
-  }
-
-  SmallVector<directory_iterator, 2> Iters;
-  switch (Redirection) {
-  case RedirectKind::Fallthrough:
-    Iters.push_back(ExternalIter);
-    Iters.push_back(RedirectIter);
-    break;
-  case RedirectKind::Fallback:
-    Iters.push_back(RedirectIter);
-    Iters.push_back(ExternalIter);
-    break;
-  default:
-    llvm_unreachable("unhandled RedirectKind");
-  }
-
-  directory_iterator Combined{
-      std::make_shared<CombiningDirIterImpl>(Iters, EC)};
-  if (EC)
-    return {};
-  return Combined;
-}
-
-void RedirectingFileSystem::setFallthrough(bool Fallthrough) {
-  if (Fallthrough) {
-    Redirection = RedirectingFileSystem::RedirectKind::Fallthrough;
-  } else {
-    Redirection = RedirectingFileSystem::RedirectKind::RedirectOnly;
-  }
-}
-
-void RedirectingFileSystem::setRedirection(
-    RedirectingFileSystem::RedirectKind Kind) {
-  Redirection = Kind;
-}
-
 std::vector<StringRef> RedirectingFileSystem::getRoots() const {
   std::vector<StringRef> R;
   for (const auto &Root : Roots)
     R.push_back(Root->getName());
   return R;
 }
 
 void RedirectingFileSystem::printImpl(raw_ostream &OS, PrintType Type,
enum class RedirectKind {
     /// "fallback".
     Fallback,
     /// Do not perform any more operations on further VFS.
     RedirectOnly
   };
 
   std::unique_ptr<RedirectingFileSystem> FS;
   RedirectKind Redirection;
-
-  // TODO: Remove after simplifying RedirectingFileSystem
-  static RedirectingFileSystem::RedirectKind
-  toRFSKind(RedirectKind Redirection) {
-    switch (Redirection) {
-    case RedirectKind::Fallthrough:
-      return RedirectingFileSystem::RedirectKind::Fallthrough;
-    case RedirectKind::Fallback:
-      return RedirectingFileSystem::RedirectKind::Fallback;
-    case RedirectKind::RedirectOnly:
-      return RedirectingFileSystem::RedirectKind::RedirectOnly;
-    }
-  }
 };
 
 } // namespace
 
 /// A helper class to hold the common YAML parsing state.
 class llvm::vfs::RedirectingFileSystemParser {
   yaml::Stream &Stream;
 
for (auto &I : *Top) {
         }
 
         bool ShouldFallthrough = false;
         if (!parseScalarBool(I.getValue(), ShouldFallthrough))
           return None;
 
         if (ShouldFallthrough) {
           Result.Redirection = YAMLParseResult::RedirectKind::Fallthrough;
-          // TODO: Remove after simplifying RedirectingFileSystem
-          Result.FS->Redirection =
-              RedirectingFileSystem::RedirectKind::Fallthrough;
         } else {
           Result.Redirection = YAMLParseResult::RedirectKind::RedirectOnly;
-          // TODO: Remove after simplifying RedirectingFileSystem
-          Result.FS->Redirection =
-              RedirectingFileSystem::RedirectKind::RedirectOnly;
         }
       } else if (Key == "redirecting-with") {
         if (Keys["fallthrough"].Seen) {
           error(I.getValue(),
                 "'fallthrough' and 'redirecting-with' are mutually exclusive");
           return None;
         }
 
         if (auto Kind = parseRedirectKind(I.getValue())) {
           Result.Redirection = *Kind;
-          // TODO: Remove after simplifying RedirectingFileSystem
-          Result.FS->Redirection = YAMLParseResult::toRFSKind(*Kind);
         } else {
           error(I.getValue(), "expected valid redirect kind");
           return None;
         }
       } else {
         llvm_unreachable("key missing from Keys");
       }
     }
RedirectingFileSystem::makeCanonical(SmallVectorImpl<char> &Path) const {
   if (CanonicalPath.empty())
     return make_error_code(llvm::errc::invalid_argument);
 
   Path.assign(CanonicalPath.begin(), CanonicalPath.end());
   return {};
 }
 
 ErrorOr<RedirectingFileSystem::LookupResult>
-RedirectingFileSystem::lookupPath(StringRef Path) const {
-  sys::path::const_iterator Start = sys::path::begin(Path);
-  sys::path::const_iterator End = sys::path::end(Path);
+RedirectingFileSystem::lookupPath(StringRef CanonicalPath) const {
+  sys::path::const_iterator Start = sys::path::begin(CanonicalPath);
+  sys::path::const_iterator End = sys::path::end(CanonicalPath);
   for (const auto &Root : Roots) {
     ErrorOr<RedirectingFileSystem::LookupResult> Result =
         lookupPathImpl(Start, End, Root.get());
     if (Result || Result.getError() != llvm::errc::no_such_file_or_directory)
       return Result;
   }
   return make_error_code(llvm::errc::no_such_file_or_directory);
 }
ErrorOr<RedirectingFileSystem::LookupResult> Result =
         lookupPathImpl(Start, End, DirEntry.get());
     if (Result || Result.getError() != llvm::errc::no_such_file_or_directory)
       return Result;
   }
 
   return make_error_code(llvm::errc::no_such_file_or_directory);
 }
 
-static Status getRedirectedFileStatus(const Twine &OriginalPath,
-                                      bool UseExternalNames,
-                                      Status ExternalStatus) {
-  Status S = ExternalStatus;
-  if (!UseExternalNames)
-    S = Status::copyWithNewName(S, OriginalPath);
-  S.IsVFSMapped = true;
-  return S;
-}
-
-ErrorOr<Status> RedirectingFileSystem::status(
-    const Twine &CanonicalPath, const Twine &OriginalPath,
-    const RedirectingFileSystem::LookupResult &Result) {
-  if (Optional<StringRef> ExtRedirect = Result.getExternalRedirect()) {
-    SmallString<256> CanonicalRemappedPath((*ExtRedirect).str());
-    if (std::error_code EC = makeCanonical(CanonicalRemappedPath))
-      return EC;
-
-    ErrorOr<Status> S = ExternalFS->status(CanonicalRemappedPath);
-    if (!S)
-      return S;
-    S = Status::copyWithNewName(*S, *ExtRedirect);
-    auto *RE = cast<RedirectingFileSystem::RemapEntry>(Result.E);
-    return getRedirectedFileStatus(OriginalPath,
-                                   RE->useExternalName(UseExternalNames), *S);
-  }
-
-  auto *DE = cast<RedirectingFileSystem::DirectoryEntry>(Result.E);
-  return Status::copyWithNewName(DE->getStatus(), CanonicalPath);
-}
-
-ErrorOr<Status>
-RedirectingFileSystem::getExternalStatus(const Twine &CanonicalPath,
-                                         const Twine &OriginalPath) const {
-  if (auto Result = ExternalFS->status(CanonicalPath)) {
-    return Result.get().copyWithNewName(Result.get(), OriginalPath);
-  } else {
-    return Result.getError();
-  }
-}
-
 ErrorOr<Status> RedirectingFileSystem::status(const Twine &OriginalPath) {
   SmallString<256> CanonicalPath;
   OriginalPath.toVector(CanonicalPath);
-
   if (std::error_code EC = makeCanonical(CanonicalPath))
     return EC;
 
-  if (Redirection == RedirectKind::Fallback) {
-    // Attempt to find the original file first, only falling back to the
-    // mapped file if that fails.
-    ErrorOr<Status> S = getExternalStatus(CanonicalPath, OriginalPath);
-    if (S)
-      return S;
-  }
-
   ErrorOr<RedirectingFileSystem::LookupResult> Result =
       lookupPath(CanonicalPath);
-  if (!Result) {
-    // Was not able to map file, fallthrough to using the original path if
-    // that was the specified redirection type.
-    if (Redirection == RedirectKind::Fallthrough &&
-        isFileNotFound(Result.getError()))
-      return getExternalStatus(CanonicalPath, OriginalPath);
+  if (!Result)
     return Result.getError();
-  }
 
-  ErrorOr<Status> S = status(CanonicalPath, OriginalPath, *Result);
-  if (!S && Redirection == RedirectKind::Fallthrough &&
-      isFileNotFound(S.getError(), Result->E)) {
-    // Mapped the file but it wasn't found in the underlying filesystem,
-    // fallthrough to using the original path if that was the specified
-    // redirection type.
-    return getExternalStatus(CanonicalPath, OriginalPath);
+  Optional<StringRef> ExtRedirect = Result->getExternalRedirect();
+  if (!ExtRedirect) {
+    auto *DE = cast<RedirectingFileSystem::DirectoryEntry>(Result->E);
+    Status S = DE->getStatus();
+    if (!UseExternalNames)
+      S = Status::copyWithNewName(S, OriginalPath);
+    else
+      S = Status::copyWithNewName(S, CanonicalPath);
+    S.IsVFSMapped = true;
+    return S;
   }
 
+  ErrorOr<Status> S = ExternalFS->status(*ExtRedirect);
+  if (!S)
+    return S;
+
+  auto *RE = cast<RedirectingFileSystem::RemapEntry>(Result->E);
+  if (!RE->useExternalName(UseExternalNames))
+    S = Status::copyWithNewName(*S, OriginalPath);
+  S->IsVFSMapped = true;
   return S;
 }
 
 namespace {
 
 /// Provide a file wrapper with an overriden status.
 class FileWithFixedStatus : public File {
   std::unique_ptr<File> InnerFile;
if (Name && Name.get() != P.str())
     F->get()->setPath(P);
   return F;
 }
 
 ErrorOr<std::unique_ptr<File>>
 RedirectingFileSystem::openFileForRead(const Twine &OriginalPath) {
   SmallString<256> CanonicalPath;
   OriginalPath.toVector(CanonicalPath);
-
   if (std::error_code EC = makeCanonical(CanonicalPath))
     return EC;
 
-  if (Redirection == RedirectKind::Fallback) {
-    // Attempt to find the original file first, only falling back to the
-    // mapped file if that fails.
-    auto F = File::getWithPath(ExternalFS->openFileForRead(CanonicalPath),
-                               OriginalPath);
-    if (F)
-      return F;
-  }
-
   ErrorOr<RedirectingFileSystem::LookupResult> Result =
       lookupPath(CanonicalPath);
-  if (!Result) {
-    // Was not able to map file, fallthrough to using the original path if
-    // that was the specified redirection type.
-    if (Redirection == RedirectKind::Fallthrough &&
-        isFileNotFound(Result.getError()))
-      return File::getWithPath(ExternalFS->openFileForRead(CanonicalPath),
-                               OriginalPath);
+  if (!Result)
     return Result.getError();
-  }
 
-  if (!Result->getExternalRedirect()) // FIXME: errc::not_a_file?
+  Optional<StringRef> ExtRedirect = Result->getExternalRedirect();
+  if (!ExtRedirect)
     return make_error_code(llvm::errc::invalid_argument);
 
-  StringRef ExtRedirect = *Result->getExternalRedirect();
-  SmallString<256> CanonicalRemappedPath(ExtRedirect.str());
-  if (std::error_code EC = makeCanonical(CanonicalRemappedPath))
-    return EC;
-
   auto *RE = cast<RedirectingFileSystem::RemapEntry>(Result->E);
-
-  auto ExternalFile = File::getWithPath(
-      ExternalFS->openFileForRead(CanonicalRemappedPath), ExtRedirect);
-  if (!ExternalFile) {
-    if (Redirection == RedirectKind::Fallthrough &&
-        isFileNotFound(ExternalFile.getError(), Result->E)) {
-      // Mapped the file but it wasn't found in the underlying filesystem,
-      // fallthrough to using the original path if that was the specified
-      // redirection type.
-      return File::getWithPath(ExternalFS->openFileForRead(CanonicalPath),
-                               OriginalPath);
-    }
+  ErrorOr<std::unique_ptr<File>> ExternalFile =
+      ExternalFS->openFileForRead(*ExtRedirect);
+  if (!RE->useExternalName(UseExternalNames))
+    ExternalFile = File::getWithPath(std::move(ExternalFile), OriginalPath);
+  if (!ExternalFile)
     return ExternalFile;
-  }
 
-  auto ExternalStatus = (*ExternalFile)->status();
+  ErrorOr<Status> ExternalStatus = (*ExternalFile)->status();
   if (!ExternalStatus)
     return ExternalStatus.getError();
-
-  // Otherwise, the file was successfully remapped. Mark it as such. Also
-  // replace the underlying path if the external name is being used.
-  Status S = getRedirectedFileStatus(
-      OriginalPath, RE->useExternalName(UseExternalNames), *ExternalStatus);
-  return std::unique_ptr<File>(
-      std::make_unique<FileWithFixedStatus>(std::move(*ExternalFile), S));
+  ExternalStatus->IsVFSMapped = true;
+  return std::make_unique<FileWithFixedStatus>(std::move(*ExternalFile),
+                                               *ExternalStatus);
 }
 
 std::error_code
 RedirectingFileSystem::getRealPath(const Twine &OriginalPath,
                                    SmallVectorImpl<char> &Output) const {
   SmallString<256> CanonicalPath;
   OriginalPath.toVector(CanonicalPath);
-
   if (std::error_code EC = makeCanonical(CanonicalPath))
     return EC;
 
-  if (Redirection == RedirectKind::Fallback) {
-    // Attempt to find the original file first, only falling back to the
-    // mapped file if that fails.
-    std::error_code EC = ExternalFS->getRealPath(CanonicalPath, Output);
-    if (!EC)
-      return EC;
-  }
-
   ErrorOr<RedirectingFileSystem::LookupResult> Result =
       lookupPath(CanonicalPath);
-  if (!Result) {
-    // Was not able to map file, fallthrough to using the original path if
-    // that was the specified redirection type.
-    if (Redirection == RedirectKind::Fallthrough &&
-        isFileNotFound(Result.getError()))
-      return ExternalFS->getRealPath(CanonicalPath, Output);
+  if (!Result)
     return Result.getError();
-  }
 
-  // If we found FileEntry or DirectoryRemapEntry, look up the mapped
-  // path in the external file system.
-  if (auto ExtRedirect = Result->getExternalRedirect()) {
-    auto P = ExternalFS->getRealPath(*ExtRedirect, Output);
-    if (P && Redirection == RedirectKind::Fallthrough &&
-        isFileNotFound(P, Result->E)) {
-      // Mapped the file but it wasn't found in the underlying filesystem,
-      // fallthrough to using the original path if that was the specified
-      // redirection type.
-      return ExternalFS->getRealPath(CanonicalPath, Output);
-    }
-    return P;
-  }
-
-  // If we found a DirectoryEntry, still fallthrough to the original path if
-  // allowed, because directories don't have a single external contents path.
-  if (Redirection == RedirectKind::Fallthrough)
-    return ExternalFS->getRealPath(CanonicalPath, Output);
-  return llvm::errc::invalid_argument;
+  if (Optional<StringRef> ExternalRedirect = Result->getExternalRedirect())
+    return ExternalFS->getRealPath(*ExternalRedirect, Output);
+
+  // Otherwise we have a DirectoryEntry, just use its path
+  Output.assign(CanonicalPath);
+  return {};
 }
 
 std::unique_ptr<FileSystem>
 vfs::getVFSFromYAML(std::unique_ptr<MemoryBuffer> Buffer,
                     SourceMgr::DiagHandlerTy DiagHandler,
                     StringRef YAMLFilePath, void *DiagContext,
                     IntrusiveRefCntPtr<FileSystem> ExternalFS) {
   MemoryBufferRef BufferRef{Buffer->getBuffer(), YAMLFilePath};
for (MemoryBufferRef Buffer : YAMLOverlays) {
     }
 
     Optional<YAMLParseResult> Result =
         RedirectingFileSystemParser::parse(Buffer, SM, ExternalFS);
     if (!Result)
       return createFileError(Buffer.getBufferIdentifier(),
                              llvm::errc::invalid_argument);
 
-    // TODO: Remove after simplifying RedirectingFileSystem
-    Result->FS->setRedirection(
-        RedirectingFileSystem::RedirectKind::RedirectOnly);
     switch (Result->Redirection) {
     case YAMLParseResult::RedirectKind::Fallthrough:
       // Simple case - add on the FS
       Overlays.emplace_back(*Result);
       OverlayFS->pushOverlay(Overlays.back().FS);
       break;
     case YAMLParseResult::RedirectKind::Fallback:
       // Fallback implies that the previously added FS should run operations

llvm/unittests/Support/VirtualFileSystemTest.cpp

TEST_F(VFSFromYAMLTest, RemappedDirectoryOverlayNoFallthrough) {
 
   Lower->addRegularFile("//root/foo/b");
   checkContents(FS->dir_begin("//root/bar", EC),
                 {"//root/foo/a", "//root/foo/b"});
 
   EXPECT_EQ(0, NumDiagnostics);
 }
 
-TEST_F(VFSFromYAMLTest, ReturnsRequestedPathVFSMiss) {
+TEST_F(VFSFromYAMLTest, RelativeVFSPathMiss) {
   IntrusiveRefCntPtr<vfs::InMemoryFileSystem> BaseFS(
       new vfs::InMemoryFileSystem);
   BaseFS->addFile("//root/foo/a", 0,
                   MemoryBuffer::getMemBuffer("contents of a"));
   ASSERT_FALSE(BaseFS->setCurrentWorkingDirectory("//root/foo"));
+
   auto RemappedFS = vfs::RedirectingFileSystem::create(
       {}, /*UseExternalNames=*/false, *BaseFS);
 
-  auto OpenedF = RemappedFS->openFileForRead("a");
+  auto OpenedF = BaseFS->openFileForRead("a");
   ASSERT_FALSE(OpenedF.getError());
-  llvm::ErrorOr<std::string> Name = (*OpenedF)->getName();
-  ASSERT_FALSE(Name.getError());
-  EXPECT_EQ("a", Name.get());
 
-  auto OpenedS = (*OpenedF)->status();
-  ASSERT_FALSE(OpenedS.getError());
-  EXPECT_EQ("a", OpenedS->getName());
-  EXPECT_FALSE(OpenedS->IsVFSMapped);
-
-  auto DirectS = RemappedFS->status("a");
-  ASSERT_FALSE(DirectS.getError());
-  EXPECT_EQ("a", DirectS->getName());
-  EXPECT_FALSE(DirectS->IsVFSMapped);
+  OpenedF = RemappedFS->openFileForRead("a");
+  ASSERT_TRUE(OpenedF.getError());
 
   EXPECT_EQ(0, NumDiagnostics);
 }
 
 TEST_F(VFSFromYAMLTest, ReturnsExternalPathVFSHit) {
   IntrusiveRefCntPtr<vfs::InMemoryFileSystem> BaseFS(
       new vfs::InMemoryFileSystem);
   BaseFS->addFile("//root/foo/realname", 0,
ASSERT_EQ("RedirectingFileSystem (UseExternalNames: true)\n"
             "  'vdir'\n"
             "    'dremap' -> '/b' (UseExternalName: true)\n"
             "    'vfile' -> '/c' (UseExternalName: false)\n"
             "ExternalFS:\n"
             "  DummyFileSystem (RecursiveContents)\n",
             Output);
 }
 
+TEST(RedirectingFileSystemTest, Basic) {
+  auto Real = makeIntrusiveRefCnt<DummyFileSystem>();
+  Real->addRegularFile("/real/f");
+
+  SmallVector<std::pair<std::string, std::string>> Mappings = {
+      {"/vfs/a", "/real/f"}};
+  auto FS = vfs::RedirectingFileSystem::create(Mappings, true, *Real);
+  ASSERT_TRUE(FS);
+
+  EXPECT_PATHS(*FS, "/vfs/a", "/real/f", "/real/f");
+
+  // Should not check ExternalFS
+  auto S = FS->status("/real/f");
+  ASSERT_TRUE(S.getError());
+
+  FS = vfs::RedirectingFileSystem::create(Mappings, false, *Real);
+  ASSERT_TRUE(FS);
+
+  // Returning the original path for realpath doesn't make sense, so expect the
+  // external here
+  EXPECT_PATHS(*FS, "/vfs/a", "/vfs/a", "/real/f");
+}
+
+// Check that a mapped directory and its parents all return a status with the
+// correct path
+TEST(RedirectingFileSystemTest, DirectoryStatus) {
+  auto Real = makeIntrusiveRefCnt<DummyFileSystem>();
+  Real->addDirectory("/real");
+
+  SmallVector<std::pair<std::string, std::string>> Mappings = {
+      {"/a/b/c", "/real"}};
+  auto FS = vfs::RedirectingFileSystem::create(Mappings, true, *Real);
+  ASSERT_TRUE(FS);
+
+  auto S = FS->status("/a");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("/a", S->getName());
+
+  S = FS->status("/a/b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("/a/b", S->getName());
+
+  S = FS->status("/a/b/c");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("/real", S->getName());
+
+  FS->setCurrentWorkingDirectory("/a");
+
+  S = FS->status("b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("/a/b", S->getName());
+
+  S = FS->status("b/c");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("/real", S->getName());
+
+  FS = vfs::RedirectingFileSystem::create(Mappings, false, *Real);
+  ASSERT_TRUE(FS);
+
+  // External names is false, use the passed in path instead
+  FS->setCurrentWorkingDirectory("/a");
+
+  S = FS->status("b");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("b", S->getName());
+
+  S = FS->status("b/c");
+  ASSERT_FALSE(S.getError());
+  EXPECT_EQ("b/c", S->getName());
+}
+
 static std::unique_ptr<vfs::OverlayFileSystem>
 getVFSOrNull(ArrayRef<std::string> YAMLOverlays,
              IntrusiveRefCntPtr<vfs::FileSystem> ExternalFS) {
   SmallVector<MemoryBufferRef> OverlayRefs;
   for (const auto &Overlay : YAMLOverlays) {
     OverlayRefs.emplace_back(Overlay, "");
   }