I can understand it being a performance or stability issue if there was a recursive loop, but there are a bunch of cases where e.g. a framework or binary version is pointed at by a symlink to indicate 'latest'/'active'…

I don’t think we have a table that reads symlinks; I see we have the

file

table that detects if a file is a symlink or not. I think it might make sense to have an optional column where we use the

readlink

API (on Unix) to read the symlink target, but from there it’s a bit tricky. The symlink could point to another symlink; the

readlink

API always reads the “contents” of the first symlink but doesn’t expand it further. In that case if you want the path to be expanded until you find a file, we would have to put a depth limit. At the same time while the symlink may point to a real file, the path itself could be composed by symlinks; not sure if that’s something that you would need too.. but that’s likely even more tricky and potentially performance intensive depending on the number of symlinks to chase

That's at least confirmation that there's no know workarounds! I may as well put the feature request in then, it's reasonable to expect only straightforward use cases to be achievable. Even one with limited capabilities would be helpful IMO