Fix ResolveLinkTarget for intermediate symlinks

[iamhaseebn]

Fixes#118719

ResolveLinkTarget(..., returnFinalTarget: true) followed a symlink chain only when each complete current path was itself a symbolic link. Kubernetes ConfigMap layouts use an intermediate ..data directory symlink, so resolution stopped before reaching the final target.

This change:

• Resolves relative targets component by component so intermediate symbolic links are followed.
• Preserves lexical absolute targets and dangling final targets.
• Retains the existing 40-link traversal limit.
• Adds shared regression coverage for File, Directory, FileInfo, and DirectoryInfo.

Validation:

• CoreLib build completed with zero warnings and zero errors.
• System.IO.FileSystem tests: 9,618 passed, 0 failed, and 59 expected skips.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[iamhaseebn]

@dotnet-policy-service agree.

[iamhaseebn]

@dotnet-policy-service agree

[teo-tsirpanis]

I wonder if this would solve the failures in dotnet/msbuild#14482.

[iamhaseebn]

Thanks for the pointer. I checked the failing Linux and macOS tests in dotnet/msbuild#14482. This change would not fix them: it follows intermediate links after the input path itself has been identified as a symbolic link. In #14482, File.ResolveLinkTarget(Directory.GetCurrentDirectory(), true) is called on the already-resolved physical directory, so it returns null before that traversal is reached. ResolveLinkTarget is therefore not a general realpath replacement for that non-link input.

[jozkee]

On Windows, we try to open the final target and use GetFinalPathNameByHandle. If the target is unreachable, we fall back to manual traversal to preserve dangling-target behavior.

What do you think about following the same approach on Unix—first trying realpath() and then falling back to manual traversal for unreachable targets? This would resolve intermediate symlinks and better align the two implementations.

cc @tmds

[iamhaseebn]

Thanks - updated the Unix path to use realpath() first, with managed traversal fallback for unreachable targets and platform-specific symlink limits, in 5a86c11.

[jeffhandley]

@jozkee -- assigning this to you to drive in for .NET 11 RC2

[jozkee]

I'm moving this to 12.0, please see #118719 (comment).

[tmds]

ResolveLinkTarget(..., returnFinalTarget: true)

For returnFinalTarget: false there is also an issue.

vardir=Directory.CreateTempSubdirectory();Directory.CreateDirectory($"{dir}/deep/deeper");Directory.CreateSymbolicLink($"{dir}/deep/deeper/link","../deeper");Directory.CreateSymbolicLink($"{dir}/a","deep/deeper");foreach(varfollowinnew[]{true,false}){vartarget=newDirectoryInfo($"{dir}/a/link").ResolveLinkTarget(follow);Console.WriteLine(target!.Exists);}

With the changes from this PR, this prints:

True
False

The problem is that the FileSystemInfo ends up with a subpath like a/.. for which the full path is '' but the resolved path is deep. (Except for ToString and Name) the FSI members work on the full path.

From a use-case perspective, I don't think users actually want/need returnFinalTarget: false. So rather than trying to fix it, it may be an option to obsolete the method and add an overload which accepts no argument (and has returnFinalTarget: true behavior).

[tmds]

The problem is that the FileSystemInfo ends up with a subpath like a/.. for which the full path is '' but the resolved path is deep. (Except for ToString and Name) the FSI members work on the full path.

Also for returnFinalTarget: true, a non-existing path might cause a subpath like a/.. for the final resolved path which can then cause the same problem. It might be good to also have the realpath semantics of returning null when the target does not exist.