Preview 7 Improper LinkTarget returned for a Directory Junction on Windows

[fitdev]

When a directory is a junction (as opposed to being a regular directory or a symlink) on Windows, as of Preview 7, DirectoryInfo.LinkTarget returns a non-null value, which is wrong. Considering a structure like this:

C:\Test\RealFolder
C:\Test\JunctionToRealFolder -> C:\Test\RealFolder
C:\Test\SymlinkToRealFolder -> C:\Test\RealFolder

DirectoryInfo.LinkTarget for C:\Test\JunctionToRealFolder returns \Test\RealFolder (instead of C:\Test\RealFolder)
DirectoryInfo.LinkTarget for C:\Test\SymlinkToRealFolder returns C:\Test\RealFolder (which is correct)

Strangely, DirectoryInfo.ResolveLinkTarget(returnFinalTarget: true) returns the correct target in all cases (Junction and Symlink).

I suspect the issue comes that you have an incorrect check for a reparse tag kind in your code:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/FileSystem.Windows.cs

Line 506 in eeee548

if ((rdb.ReparseTag & Interop.Kernel32.IOReparseOptions.IO_REPARSE_TAG_SYMLINK) == 0)

Should instead be:

if (rdb.ReparseTag != Interop.Kernel32.IOReparseOptions.IO_REPARSE_TAG_SYMLINK)

Since you say you support symlinks only ATM.

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Main Issue

When a directory is a junction (as opposed to being a regular directory or a symlink) on Windows, as of Preview 7, DirectoryInfo.LinkTarget returns a non-null value, which is wrong. Considering a structure like this:

C:\Test\RealFolder
C:\Test\JunctionToRealFolder -> C:\Test\RealFolder
C:\Test\SymlinkToRealFolder -> C:\Test\RealFolder

DirectoryInfo.LinkTarget for C:\Test\JunctionToRealFolder returns \Test\RealFolder (instead of C:\Test\RealFolder)
DirectoryInfo.LinkTarget for C:\Test\SymlinkToRealFolder returns C:\Test\RealFolder (which is correct)

Strangely, DirectoryInfo.ResolveLinkTarget(returnFinalTarget: true) returns the correct target in all cases (Junction and Symlink).

I suspect the issue comes that you have an incorrect check for a reparse tag kind in your code:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/FileSystem.Windows.cs

Line 506 in eeee548

if ((rdb.ReparseTag & Interop.Kernel32.IOReparseOptions.IO_REPARSE_TAG_SYMLINK) == 0)

Should instead be:

if (rdb.ReparseTag != Interop.Kernel32.IOReparseOptions.IO_REPARSE_TAG_SYMLINK)

Since you say you support symlinks only ATM.

Smaller issue

On Windows, there is an inconsistency of final targets returned depending on which APIs are used, and whether or not virtual drives created with subst command are used in the path (both the link and the target residing on such virtual drives):

The DirectoryInfo.ResolveLinkTarget(returnFinalTarget: true) API (and other APIs you added that resolve final target) resolve the final target to non-virtual drives, while the DirectoryInfo.LinkTarget (and other similar APIs that resolve the immediate target), when called repeatedly while LinkTarget != null stop at the virtual drive level.

So, given a structure like this:

C:\RootDirectoryForVirtualDriveX
X:\SomeRealFolder
X:\SymlinkToRealFolderOnX -> X:\SomeRealFolder

Calling DirectoryInfo.ResolveLinkTarget(returnFinalTarget: true) on X:\SymlinkToRealFolderOnX will result in: C:\RootDirectoryForVirtualDriveX\SomeRealFolder

While calling DirectoryInfo.LinkTarget (repeatedly while the result is non-null) on X:\SymlinkToRealFolderOnX will result in: X:\SomeRealFolder

Even though, logically, and for consistency results should be the same.

Author:	fitdev
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[adamsitnik]

@carlossanlop @jozkee PTAL

[carlossanlop]

Thanks for your report, @fitdev

The "main issue" should get moved to 7.0. As you correctly stated, we only support symlinks at the moment.

I'm moving the "smaller issue" into a separate issue, and we can then determine if it should be fixed for 6.0 or 7.0.

[fitdev]

@carlossanlop Thanks for looking into this. However this issue was not about supporting Junctions. It was about a bug in Preview 7 and your current code that basically returns a target (i.e. non-null string) even if the directory is a Junction. Instead it should return null then, and certainly NOT the totally erroneous path as it does currently.

I mean if DotNet 6 does not support Junctions, then it should not support them at all, i.e. LinkTarget and ResolveLinkTarget should all return null if directory is a junction, i.e. treat it as a regular directory. But right now it seems to be semi-supported in a very buggy way (no way to distinguish between is this a symlink or a junction dir, since in both cases LinkTarget is not null).

[carlossanlop]

Good point, @fitdev. I'll mark it for 6.0 and return null for junctions.