From d31d2bc74c884ff5d7932b1f6e7209c6fc63cc5e Mon Sep 17 00:00:00 2001 From: cvgw Date: Mon, 17 Feb 2020 13:32:28 -0800 Subject: [PATCH] update about filesWithParentDirs --- .../filesystem-resolution-proposal-01.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/design_proposals/filesystem-resolution-proposal-01.md b/docs/design_proposals/filesystem-resolution-proposal-01.md index 741bd59c7..205c2a882 100644 --- a/docs/design_proposals/filesystem-resolution-proposal-01.md +++ b/docs/design_proposals/filesystem-resolution-proposal-01.md @@ -87,6 +87,11 @@ The API will iterate over the set of filepaths and for each item * check whether the target is whitelisted and if not add the target to the output +All ancestors of each filepath will also be added to the list, but the previous +checks will not be applied to the ancestors. This maintains the current behavior +which we believe is needed to maintain correct permissions on the ancestor +directories. + ### Open Issues/Questions \ @@ -109,7 +114,9 @@ current whitelist logic it is possible for `/some/dir` to be whitelisted but not ancestors does it make most sense to handle this within the proposed filtering API? -Resolution: Not Yet Resolved +Resolution: Resolved + +Yes, this should be handled in the API \