Tape stage api fails to respect supplied arguments when handlign symlinks #7693
Assignees
Comments
DmitryLitvintsev
added a commit
to DmitryLitvintsev/dcache
that referenced
this issue
Nov 26, 2024
Motivation: ---------- Bulk request keepts target arguments that have been supplied by the user. These arguments contain target paths that may be symbolic links. When, during request processing, the resolved target paths are matched to path keys in arguments map to find out argument values (like lifetime). If keys contain symbolic links no match is made and thus user supplied lifetime argument values are not picked up falling back to default. Modification: ------------ Commit fff8b79 stores full target path in target and target arguments structuress. There is no discernable need to resolve symbolic link as fetch of attributes can be done on synlinked paths. Remove the step of path resolution in BulkRequestContainerJob completely. Result: ------- Correct behavior of tape rest API when using symbolic links Issue: dCache#7693 Target: trunk Request: 10.2, 10.1, 10.0, 9.2 Require-book: no Require-notes: yes Signed-off-by: Dmitry Litvintsev <[email protected]>
DmitryLitvintsev
added a commit
to DmitryLitvintsev/dcache
that referenced
this issue
Nov 27, 2024
Motivation: ---------- Recent change(s) that massaged user input target paths and stored absolute paths on bulk backend lead to ambiguity between user provided and dcache paths and also resulted in inability to use full paths (i.e. only relative paths are supported). At Fermilab we need to use both - relative and absolute paths Modification: ------------ Revert all recent changes that appended prefix to user supplied paths, stored the result and then stripped the prefix so that only "original" paths are exposed to the user. Instead, like before, store user supplied paths but carry over request prefix which is computed from user root and door root. When calling PnfsManager using paths the full patths of the targets are reassebled using the prefix Result: ------- Restored ability to use absolute paths when using REST API. Issue: dCache#7693 Target: trunk Request: 10.2, 10.1, 10.0, 9.2 Require-book: no Require-notes: yes Signed-off-by: Dmitry Litvintsev [email protected]
DmitryLitvintsev
added a commit
to DmitryLitvintsev/dcache
that referenced
this issue
Nov 27, 2024
Motivation: ---------- Recent change(s) that massaged user input target paths and stored absolute paths on bulk backend lead to ambiguity between user provided and dcache paths and also resulted in inability to use full paths (i.e. only relative paths are supported). At Fermilab we need to use both - relative and absolute paths Modification: ------------ Revert all recent changes that appended prefix to user supplied paths, stored the result and then stripped the prefix so that only "original" paths are exposed to the user. Instead, like before, store user supplied paths but carry over request prefix which is computed from user root and door root. When calling PnfsManager using paths the full patths of the targets are reassembled using the prefix Result: ------ Restored ability to use absolute paths when using REST API. Issue: dCache#7693 Target: trunk Request: 10.2, 10.1, 10.0, 9.2 Require-book: no Require-notes: yes Signed-off-by: Dmitry Litvintsev [email protected]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is issue is somewhat similar #7687
When the list of request arguments is built they go in verbatim as specified by user, ending up as a map <path, parameter> . The path can be symlink. Later in processing of request the path is resolved to the actual path, then that resolved path is used to find parameters by trying to match the key in that map. Since original path != symlinked path parameters are failed to be found.
Result - inability to set diskFileLifetime on symbolic link
The text was updated successfully, but these errors were encountered: