_relative_symlink_target depends on the host filing system
Summary
The function _relative_symlink_target
attempts to turn absolute symlinks into relative ones (relative to a particular directory passed as 'root'). It also attempts to resolve any symlinks which are present in the target of the symlink. It uses os.path.realpath to do this. This introduces a dependency on the host file system.
Further, any modification of the symlink target is undesirable; we should leave absolute symlinks as is, and change our resolution of them, if we ever have to.
Example
This is theoretical; no reproduction case has been found yet. However, see #647 (closed) which demonstrates that paths containing symlinks could be resolved by this.
This is an example call:
_relative_symlink_target('/home/jimmacarthur/.cache/buildstream/build/acl-5o7v8tlb/artifact/buildtree', '/home/jimmacarthur/.cache/buildstream/build/acl-5o7v8tlb/artifact/buildtree/bst_build_dir/include/acl',
'/buildstream/freedesktop-sdk-bootstrap/acl.bst/bst_build_dir/../include')
Both the first and second argument are passed into realpath
. Anything in the path up to 'buildtree' could be a symlink, and can change between two calls to realpath
, so the results could be completely changed by the host's file system.
Note that there are two separate issues here: one is the conversion of the symlink's target from absolute to relative, and the second is the resolution of any further symlinks which are found in the path of the target.
What is the expected correct behaviour?
We should never ask the host operating system to resolve absolute symlinks. It is possible to turn an absolute symlink into a relative one using os.path.relpath
, which we already do. We just need to remove the calls to realpath
. If we decide that we need to resolve symlinks in the target, we should do our own resolution rather than using realpath
. However, we may decide that we don't need to do that at all.
There is a further argument that we should not convert absolute symlinks to relative ones at all; this is not part of this issue.
Possible fixes
Valentin's MR !862 (closed) already includes a host-independent symlink resolver, and CASVirtualDirectory
has its own internal resolver.