Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Duplicate
-
None
-
None
-
None
-
None
Description
Take for example a path such as:
/tmp/mesos/slaves/20141010-224838-16842879-5050-31526-6/frameworks/20141010-224838-16842879-5050-31526-0006/executors/visualizer/runs/55ba8d8e-adb6-438e-b14c-c564e6495cae
This will be stored in the paths hashmap in files/files.cpp with the leading slash:
"/tmp/mesos/slaves/20141010-224838-16842879-5050-31526-6/frameworks/20141010-224838-16842879-5050-31526-0006/executors/visualizer/runs/55ba8d8e-adb6-438e-b14c-c564e6495cae"
The browse.json handler takes in the full path. It then calls files::resolve. resolve will tokenize the string by "/":
{"", "tmp", "mesos", "slaves", "20141010-224838-16842879-5050-31526-6", "frameworks", "20141010-224838-16842879-5050-31526-0006", "executors", "visualizer", "runs", "55ba8d8e-adb6-438e-b14c-c564e6495cae"}Each prefix is tested against the paths hashmap (e.g. "/tmp/mesos", "/tmp/mesos/slaves", etc.). However, paths::join will discard the leading slash. So the test will be with the key:
"tmp/mesos/slaves/20141010-224838-16842879-5050-31526-6/frameworks/20141010-224838-16842879-5050-31526-0006/executors/visualizer/runs/55ba8d8e-adb6-438e-b14c-c564e6495cae"
Since the hashmap contains keys with leading slashes and paths::join will return strings without leading slashes, files::resolve will always fail.
https://reviews.apache.org/r/25818/ appears to be the breaking change.
There are several tests which should test the leading slash behavior, but the expected result doesn't make sense with respect to how path::join is used in files::resolve.
3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp
Seems like either the implementation and tests are wrong or the use of path::join in files::resolve is wrong.
Attachments
Issue Links
- duplicates
-
MESOS-1878 Access to sandbox on slave from master UI does not show the sandbox contents
- Resolved