[PATCH] D17104: [VFS] Drop path traversal assertion

Ben Langmuir via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 11 13:28:14 PST 2016


benlangmuir added a comment.

> Now, we try to use the new YAML file + cache from a new clang invocation. When the FileManager requests status in (2) for the path "/install-dir/bin/../lib/clang/3.8.0/include/altivec.h" neither "remove_dots()" nor "realpath()" would be able to resolve it to "/private/tmp/a/b/lib/clang/3.8.0/include/altivec.h" and will fallback to search the real filesystem instead, if this is a different machine, it will fail. Since we are looking at a virtual path in (2) it could makes sense to use remove_dots() but it won't make sense to use "realpath()".

> 

> How do you propose we fix that?


Ugh, I forgot about this case.  Sorry for making this sound simpler than it is!

Your two-path solution seems like it's on the right track but I don't like that it brings us back to having ".." in the source path.  Do you think it's feasible to store a mapping from the realpath, and additionally have a symlink entry in the VFS (which would be a new feature for the VFS in general)?  When we write the YAML file, we could realpath(source) and if it is different from remove_dots(source) we would add a symlink entry.  I suspect figuring out whthe symlink would add non-trivial overhead, since we'd have to look at every path component... at least it would only be paid when creating the YAML, not when reading it. Any thoughts?


http://reviews.llvm.org/D17104





More information about the cfe-commits mailing list