[release/6.0-rc1] Add internal junction support to link APIs #58285
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
… refactored/removed in the future. Detect if SUBST is available in Windows machine, to bring back Nano.
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsBackport of #57996 to release/6.0-rc1 /cc @carlossanlop Customer ImpactTestingRisk
|
carlossanlop
added
the
Servicing-consider
jozkee
approved these changes
Aug 28, 2021
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #57996 to release/6.0-rc1
/cc @carlossanlop @jozkee
Customer Impact
We added new APIs to
FileSystemInfo,FileandDirectoryin 6.0 for link manipulation:CreateSymbolicLink(string pathToTarget)- For creation of a symbolic link of the specified filesystem type.ResolveLinkTarget(bool returnFinalTarget)- If the specified filesystem item represents a link, the target is returned (immediate or final target).LinkTarget- If the specified filesystem item represents a link, gets the path of the immediate target path.Initially we wanted these APIs to exclusively work with symbolic links in 6.0, then we would add support for all the other types of links in 7.0 (reparse points like junctions or app exec links).
After some discussions, and after looking at the PowerShell code (which already handles symlinks, junctions and app exec links), we decided that the
ResolveLinkTarget()andLinkTargetAPIs should be able to also resolve those other types of links. This would allow the PowerShell team to fully migrate their existing link-handling code to our new APIs (here's their code - they currently perform all the P/Invokes themselves).This PR adds only junction support for those APIs. The app exec link support will be backported in a separate PR, which is still being reviewed for main.
By adding junction support, we also fix a bug that a customer reported recently in the new APIs: when a symbolic link lives inside a virtual drive (a directory mounted on a drive letter), the symbolic link path was not getting resolved properly. This is because a virtual drive is just a junction under the covers, and we were unable to detect it and resolve its target properly.
The
CreateSymbolicLink()method will remain unaffected.Testing
Added unit tests that create junctions both in normal directories and in virtual drives. They verify if the targets are resolved, whether they are direct (link->target) or indirect (in a chain of links).
Risk
Low. These are all new APIs, and the changes only affect new code. The symbolic link logic, which was introduced in a previous Preview, is unaffected. The new logic only kicks in when the filesystem item is a junction (which are links that only work for directories).
The main benefit of this change is to address customer feedback in the new APIs. We shipped link support in preview 7, but we only added support and validated symlinks; those are a subset of reparse points in NTFS, we received feedback in that time frame asking for Junction support, another kind of reparse point, which is what this PR does.
Helping PowerShell with their existing scenarios is an additional, secondary benefit.