[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