Add symbolic link APIs #54253

carlossanlop · 2021-06-15T23:40:55Z

Co-authored with @jozkee

PTAL @iSazonov @mklement0 @tmds @carlreinke

dotnet-issue-labeler · 2021-06-15T23:41:00Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2021-06-15T23:41:04Z

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

Issue Details

Fixes #24271

Co-authored with @jozkee

PTAL @iSazonov @mklement0 @tmds @carlreinke

Author:	carlossanlop
Assignees:	carlossanlop, Jozkee
Labels:	`area-System.IO`
Milestone:	6.0.0

src/libraries/System.Private.CoreLib/src/Resources/Strings.resx

carlreinke · 2021-06-16T00:52:22Z

src/libraries/System.Private.CoreLib/src/System/IO/File.cs

+        /// <exception cref="ArgumentNullException"><paramref name="path"/> or <paramref name="pathToTarget"/> is <see langword="null"/>.</exception>
+        /// <exception cref="ArgumentException"><paramref name="path"/> or <paramref name="pathToTarget"/> is empty.
+        /// -or-
+        /// <paramref name="path"/> is not an absolute path.


This is different from File.Create, which allows path to be relative. I'm not necessarily opposed to requiring an absolute path, but it seems like it could be a gotcha.

Implementation wise we do support relative paths, similarly to any other API in System.IO. This is just a mistake in the documentation. Thanks for pointing this out.

My bad. I initially wrote the empty APIs with docs on top of them assuming some things, but didn't adjust them after writing the code. Thanks for catching it, @carlreinke. We'll make sure to double check the docs.

src/libraries/System.IO.FileSystem/tests/Base/SymbolicLinks/BaseSymbolicLinks.FileSystem.cs

carlreinke · 2021-06-16T01:01:57Z

src/libraries/System.Private.CoreLib/src/System/IO/File.cs

+        /// -or-
+        /// <paramref name="path"/> is not an absolute path.
+        /// -or-
+        /// <paramref name="path"/> or <paramref name="pathToTarget"/> contains invalid path characters.</exception>


Grouping path and pathToTarget here makes it sound like they will both be validated against the same set of invalid characters. pathToTarget allows almost anything, including most of Path.InvalidPathChars.

I wonder if the target is not the regular path?

@carlreinke, a symlink points to another file-system entry using a regular path, so it seems sensible to validate the target path formally like any other path (not in terms of existence; although, given that symlinks can span file-systems, conceivably they have different sets of valid characters - how does FileSystem.VerifyValidPath handle this currently?). Why do you think pathToTarget allows (should allow) almost anything?

@mklement0 pathToTarget allows almost anything because mklink (and thus the underlying OS API) allows almost anything in the target on Windows.

C:\temp>mklink foo "<>:/\|?*" symbolic link created for foo <<===>> <>:/\|?* C:\temp>dir | findstr foo 2021-06-16 23:08 <SYMLINK> foo [<>:/\|?*]

(On Linux the only invalid path character is '\0', so it's obvious that it will allow almost anything there.)

See this comment for a use case for storing arbitrary data in a symlink.

@carlreinke:

Wow - I certainly did not expect mklink foo "<>:/\|?*" to work, and you have to wonder why that is permitted. The implementation via reparse points means that arbitrary data can be stored, so one can see how it's technically possible, but to what end? Probably not in anticipation of "off-label" uses such as as a lock on Unix, per the comment you link to.

I guess that disallowing '\0' is then the only check we can perform without making underlying capabilities inaccessible (I haven't tried the APIs directly, but at least mklink / ln don't support '\0'.)

The only caveat is that we must make sure that other .NET APIs then don't run into trouble when they encounter a FileSystemInfo instance with such a misshapen path obtained via .ResolveLinkTarget() - note that
new FileInfo("<>:/\|?*") does not work, for instance.

And, of course, this permissiveness should be clearly documented.

De-facto only OS file system driver can do full path validation. In the library it makes sense only to do simple checks for null/\0.

carlreinke · 2021-06-16T01:05:58Z

src/libraries/System.Private.CoreLib/src/System/IO/File.cs

+        /// <param name="linkPath">The path of the file link.</param>
+        /// <param name="returnFinalTarget"><see langword="true"/> to follow links to the final target; <see langword="false"/> to return the immediate next link.</param>
+        /// <returns>A <see cref="FileInfo"/> instance if <paramref name="linkPath"/> exists, independently if the target exists or not. <see langword="null"/> if <paramref name="linkPath"/> does not exist.</returns>
+        public static System.IO.FileSystemInfo? ResolveLinkTarget(string linkPath, bool returnFinalTarget = false)


There are at least a couple <exception/> cases that should be listed here.

+ /// <exception cref="ArgumentNullException"><paramref name="linkPath"/> is <see langword="null"/>.</exception> + /// <exception cref="ArgumentException"><paramref name="linkPath"/> is empty. + /// -or- + /// <paramref name="linkPath"/> contains a null character.</exception>

iSazonov · 2021-06-16T04:32:27Z

src/libraries/Common/src/Interop/Unix/Interop.DefaultPathBufferSize.cs

+{
+    // Unix max paths are typically 1K or 4K UTF-8 bytes, 256 should handle the majority of paths
+    // without putting too much pressure on the stack.
+    internal const int DefaultPathBufferSize = 256;


I wonder if the team has taken any measurements on this? What is typical path size?
I would choose half of the maximum i.e. 512 so as to always have no more than one fallback (bufferSize *= 2).

Good question, I don't know if we have data around this. Since this number is used in some other APIs (and this const is now consumed in those places) I would rather not make that change now. Feel free to open an issue though.

nit: This will give us a new const for Unix, while we already have Interop.Kernel32.MAX_PATH for Windows. It would be nice to have one const for both platforms.

iSazonov · 2021-06-16T04:50:35Z

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.CreateSymbolicLink.cs

+        /// Allows creation of symbolic links when the process is not elevated. Starting with Windows 10 Insiders build 14972.
+        /// Developer Mode must first be enabled on the machine before this option will function.


Is the comment correct? Docs don't say about developer mode now
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#enable-long-paths-in-windows-10-version-1607-and-later

It's mentioned in the blog post under the "Background" section: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/

It's also documented in the dwFlags parameter of the API: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createsymboliclinka#parameters

This site is unofficial but is usually very well documented and also mentions it: https://ss64.com/nt/mklink.html

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.DeviceIoControl.cs

iSazonov · 2021-06-16T05:08:47Z

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.REPARSE_DATA_BUFFER.cs

+        // https://msdn.microsoft.com/library/windows/hardware/ff552012.aspx
+        // We don't need all the struct fields; omitting the rest.
+        [StructLayout(LayoutKind.Sequential)]
+        public unsafe struct REPARSE_DATA_BUFFER
+        {
+            public uint ReparseTag;
+            public ushort ReparseDataLength;
+            public ushort Reserved;
+            public SymbolicLinkReparseBuffer ReparseBufferSymbolicLink;
+
+            [StructLayout(LayoutKind.Sequential)]
+            public struct SymbolicLinkReparseBuffer
+            {
+                public ushort SubstituteNameOffset;
+                public ushort SubstituteNameLength;
+                public ushort PrintNameOffset;
+                public ushort PrintNameLength;
+                public uint Flags;


Since C# doesn't support C++ UNION I think it is better to define flat struct with REPARSE_DATA_BUFFER_SYMBOLICLINK name.

Suggested change

// https://msdn.microsoft.com/library/windows/hardware/ff552012.aspx

// We don't need all the struct fields; omitting the rest.

[StructLayout(LayoutKind.Sequential)]

public unsafe struct REPARSE_DATA_BUFFER

{

public uint ReparseTag;

public ushort ReparseDataLength;

public ushort Reserved;

public SymbolicLinkReparseBuffer ReparseBufferSymbolicLink;

[StructLayout(LayoutKind.Sequential)]

public struct SymbolicLinkReparseBuffer

{

public ushort SubstituteNameOffset;

public ushort SubstituteNameLength;

public ushort PrintNameOffset;

public ushort PrintNameLength;

public uint Flags;

// https://msdn.microsoft.com/library/windows/hardware/ff552012.aspx

// We don't need all the struct fields; omitting the rest.

[StructLayout(LayoutKind.Sequential)]

public unsafe struct REPARSE_DATA_BUFFER

{

public uint ReparseTag;

public ushort ReparseDataLength;

public ushort Reserved;

public ushort SubstituteNameOffset;

public ushort SubstituteNameLength;

public ushort PrintNameOffset;

public ushort PrintNameLength;

public uint Flags;

The nested struct was added for clarity and easier manipulation.

Do you have any concerns around having a nested struct, as opposed to having it all flatly defined in the top struct?

Only concern is that we will have to change this and define some structs if we will want to support other reparse points. (mount points and others). This is that we have in PowerShell code.

According to the documentation, the C++ struct containing nested union structs can define the data for a symbolic link, for a mount point and the generic type:

typedef struct _REPARSE_DATA_BUFFER { ULONG ReparseTag; USHORT ReparseDataLength; USHORT Reserved; union { struct { USHORT SubstituteNameOffset; USHORT SubstituteNameLength; USHORT PrintNameOffset; USHORT PrintNameLength; ULONG Flags; WCHAR PathBuffer[1]; } SymbolicLinkReparseBuffer; struct { USHORT SubstituteNameOffset; USHORT SubstituteNameLength; USHORT PrintNameOffset; USHORT PrintNameLength; WCHAR PathBuffer[1]; } MountPointReparseBuffer; struct { UCHAR DataBuffer[1]; } GenericReparseBuffer; } DUMMYUNIONNAME; } REPARSE_DATA_BUFFER, *PREPARSE_DATA_BUFFER;

Correct me if I'm wrong, but I think the code can be preserved as it is right now, and when the time comes to support junctions and others, we add the extra structs as needed.

we add the extra structs as needed.

I mean we can not use the same name REPARSE_DATA_BUFFER for all the structs.

I mean we can not use the same name REPARSE_DATA_BUFFER for all the structs.

Why not? My idea was to use REPARSE_DATA_BUFFER for all the pinvokes related to reparse points. Similar to what we have for symbolic links here:
https://github.com/dotnet/runtime/blob/55c1c67ad9653e82ca5d63f6bc47721321891af8/src/libraries/System.Private.CoreLib/src/System/IO/FileSystem.Windows.cs#L503

For mount points we would do rdb.MountPointReparseBuffer.SubstituteNameOffset.

Using the same name for different purposes will be misleading. For example, there will be references with the same name in searches. This will make it difficult to understand and research the code.

src/libraries/System.Private.CoreLib/src/Resources/Strings.resx

iSazonov · 2021-06-16T06:36:34Z

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

+                GetFinalLinkTarget(linkPath, isDirectory) :
+                GetImmediateLinkTarget(linkPath, isDirectory, throwOnNotFound: true, normalize: true);
+
+            return targetPath == null ? null :


Suggested change

return targetPath == null ? null :

return targetPath is null ? null :

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

iSazonov · 2021-06-16T07:17:27Z

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

+                Win32Marshal.GetExceptionForLastWin32Error(linkPath);
+            }
+
+            char* buffer = stackalloc char[Interop.Kernel32.MAX_PATH];


Can it be long path?

I discussed this with @jozkee. We should verify what happens if we pass a path that's larger than MAX_PATH. if the API can fail and tell us that the buffer was not large enough, then we could apply similar logic to what we added in the Unix side.

@iSazonov : It can.

src/libraries/System.Private.CoreLib/src/System/IO/FileSystemInfo.cs

src/libraries/System.Private.CoreLib/src/System/IO/Directory.cs

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

src/libraries/System.IO.FileSystem/tests/Base/SymbolicLinks/BaseSymbolicLinks.FileSystemInfo.cs

src/libraries/System.IO.FileSystem/tests/Base/SymbolicLinks/BaseSymbolicLinks.FileSystem.cs

src/libraries/Common/tests/TestUtilities/System/IO/FileCleanupTestBase.cs

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.CreateSymbolicLink.cs

carlossanlop · 2021-06-21T21:03:06Z

@dotnet/runtime-infrastructure the failed CI legs had a problem with Docker:

Docker pull failed with exit code 1

Value cannot be null. (Parameter 'ContainerId')

I tried restarting them but they failed again. Any clues why this is happening?

hoyosjs · 2021-06-21T21:51:44Z

This is only for the linker tests. And it's because the container failed to initialize it looks like, it seems to be unable to download the image, but I can fetch it locally. Seems like a timeout because it's a huge image (3.4 gb) and it timed out during link verification. The other legs are seeing some instability in using AzDO NuGet feeds.

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.CreateSymbolicLink.cs

src/libraries/System.Private.CoreLib/src/Resources/Strings.resx

src/libraries/Common/src/Interop/Unix/System.Native/Interop.ReadLink.cs

adamsitnik

Overall LGTM, but:

System.IO.Tests.Directory_SymbolicLinks.ResolveLinkTarget_ReturnFinalTarget_MaxFollowedLinks test is failing in one of the Windows CI legs. Please fix it before merging
If we don't know what should be the default value of bool returnFinalTarget (Add symbolic link APIs #54253 (comment)) IMO we should not provide default value and the users should provide it in explicit way.

jeffhandley · 2021-07-07T17:49:14Z

If we don't know what should be the default value of bool returnFinalTarget (Add symbolic link APIs #54253 (comment)) IMO we should not provide default value and the users should provide it in explicit way.

That sounds like a good approach to me.

jozkee · 2021-07-08T05:17:53Z

System.IO.Tests.Directory_SymbolicLinks.ResolveLinkTarget_ReturnFinalTarget_MaxFollowedLinks test is failing in one of the Windows CI legs. Please fix it before merging

This was due Windows not being consistent with the reparse point limit specified in the docs. I've loosen the validation so we now check it completes successfully with small chains of links (1, 10, 40) and check that a nice exception is thrown with large ones (100).

If we don't know what should be the default value of bool returnFinalTarget (#54253 (comment)) IMO we should not provide default value and the users should provide it in explicit way.

Done but this is an API change. cc @bartonjs @terrajobst

terrajobst · 2021-07-08T06:23:40Z

@adamsitnik @jeffhandley

If we don't know what should be the default value of bool returnFinalTarget (Add symbolic link APIs #54253 (comment)) IMO we should not provide default value and the users should provide it in explicit way.

That sounds like a good approach to me.

I'm not opposed to removing the default but I generally don't like "we can't agree so we make the user choose"-line of thinking. The reason being that we're the experts and most users won't be.

There are cases where the purpose of the parameter is immediately clear (e.g. bool recursive for Directory.Delete()). I'm not sure that this is the case here, so the result might be a coin flip.

Curious what @bartonjs thinks.

iSazonov · 2021-07-08T06:41:37Z

If we would have public class SymbolicLink it would be clear we process the entity itself and the default should be false. Here we enhance existing API and the default would rather be true as the API already partially does.

bartonjs · 2021-07-08T16:43:52Z

If we don't know what should be the default value of bool returnFinalTarget ...

I'm not opposed to removing the default but I generally don't like "we can't agree so we make the user choose"-line of thinking. The reason being that we're the experts and most users won't be.
...
Curious what @bartonjs thinks.

My standard starting position is to ask the FDG what they have to say about it:

DO provide good defaults for all properties and parameters (using convenience overloads), if possible.

OK, so if it's possible we should provide a good default. So, what makes a good default in this case? I think "predictability".

Let's imagine that we didn't have the parameter at all... so it's just ResolveTarget(), what would that do? I feel like it would return the target value of the link... so non-recursive/non-final. Now, in a future version, someone says "it'd be nice if I didn't have to write the while loop myself, especially because I keep forgetting to put in an infinite loop detector", so we add an overload. The zero-arg version is still doing a single target resolution, because that's the method name. The parameter then can control an "actually, I want to keep going" behavior.

So now lets just collapse that and look at it with a default parameter. The name of the method is ResolveTarget. Resolve is, admittedly, slightly ambiguous, so let's pretend it's named GetTarget. Well, GetTarget is obviously "give me the target value of this symlink", so link.GetTarget() would be non-recursive. To me, a similar thing applies when we let Get be called Resolve. If we think that's where the "but Resolve feels like it should keep going until final resolution", then perhaps the better change is s/ResolveTarget/GetTarget, and now "once" is the "obvious" behavior, and "keep going" is the opt-in behavior.

The problem with recursive being the default is that it has unexpected behaviors. If we have no work limiter, then mutually referential symlinks cause an infinite loop:

$ ls -al foo bar
lrwxrwxrwx 1 jbarton jbarton 3 Jul  8 09:38 bar -> foo
lrwxrwxrwx 1 jbarton jbarton 3 Jul  8 09:38 foo -> bar

If we do have a work limiter then mutually referential symlinks will.. do something. Throw, return the last one it saw when it exhausted the work factor, something. Whatever it does, you probably didn't expect it. Sure, the docs'll mention it, but no one reads the docs until something goes wrong.

To me, from a logical perspective (of how I think about things), "once" is the correct default. To me, from a security perspective (not "hiding" unexpected behaviors in server products), "once" is the correct default. So, to me, we should just figure out what makes us happy with that choice (e.g. renaming Resolve to Get).

iSazonov · 2021-07-08T19:01:00Z

To me, from a logical perspective (of how I think about things), "once" is the correct default. To me, from a security perspective (not "hiding" unexpected behaviors in server products), "once" is the correct default. So, to me, we should just figure out what makes us happy with that choice (e.g. renaming Resolve to Get).

From a logical perspective wouldn't it make more sense to have `public class Symbolic Link'?
In this case it will be clear to everyone that all actions refer to this entity (symbolic link), while if we add new extensions to the existing API it causes difficulties to understand (and implement) on every step of the way.

jozkee · 2021-07-08T23:42:49Z

@iSazonov it might be but being so close to the release, I don't think its a good idea to try to do another API from scratch. We can evaluate the public class LinkInfo : FileSystemInfo on the next releases. Shipping this in 6 can also give us an insight of how good we did in satisfying the main scenarios, if we did poorly (I hope not), we could address that in said new type.

… real temp path Bring back previous InlineData since it wasn't the cause of the CI issue

iSazonov · 2021-07-09T13:07:04Z

@jozkee @carlossanlop @adamsitnik Thanks for great work!

@jozkee I fully trust MSFT team experience. Nevertheless I am a bit nervous about link APIs based on experiences we got in the PR from discussions of details. :-) I hope we will continue discussions in proper issue - what is the issue?

jozkee · 2021-07-09T19:11:17Z

@iSazonov #51605 is the uber issue, you can comment in there or you can create a sub-issue.

jeffhandley · 2021-07-09T19:19:16Z

@iSazonov Thanks for all of your input along the way, and we certainly want and invite more input and feedback. By getting this merged in, we will be able to include these APIs in .NET 6.0 Preview 7, and solicit feedback during RC & RC2.

carlossanlop added the area-System.IO label Jun 15, 2021

carlossanlop added this to the 6.0.0 milestone Jun 15, 2021

carlossanlop requested review from jeffhandley and adamsitnik June 15, 2021 23:40

carlossanlop self-assigned this Jun 15, 2021

carlossanlop assigned jozkee Jun 15, 2021

dotnet-issue-labeler bot added the new-api-needs-documentation label Jun 15, 2021

carlossanlop force-pushed the symlinks branch from bd94882 to 482bdf3 Compare June 15, 2021 23:51

carlreinke reviewed Jun 16, 2021

View reviewed changes

src/libraries/System.Private.CoreLib/src/Resources/Strings.resx Outdated Show resolved Hide resolved

carlreinke reviewed Jun 16, 2021

View reviewed changes

jozkee reviewed Jun 16, 2021

View reviewed changes

src/libraries/System.IO.FileSystem/tests/Base/SymbolicLinks/BaseSymbolicLinks.FileSystem.cs Outdated Show resolved Hide resolved

carlreinke reviewed Jun 16, 2021

View reviewed changes

iSazonov reviewed Jun 16, 2021

View reviewed changes

carlossanlop mentioned this pull request Jun 17, 2021

Developers using filesystem APIs find them to work well with symbolic links #51605

Closed

4 tasks

iSazonov reviewed Jun 17, 2021

View reviewed changes

src/libraries/System.Private.CoreLib/src/System/IO/Directory.cs Outdated Show resolved Hide resolved

carlossanlop commented Jun 18, 2021

View reviewed changes

src/libraries/System.Private.CoreLib/src/System/IO/FileSystem.Windows.cs Outdated Show resolved Hide resolved

jozkee reviewed Jun 18, 2021

View reviewed changes

src/libraries/System.IO.FileSystem/tests/Base/SymbolicLinks/BaseSymbolicLinks.FileSystemInfo.cs Outdated Show resolved Hide resolved

jozkee reviewed Jun 18, 2021

View reviewed changes

src/libraries/System.IO.FileSystem/tests/Base/SymbolicLinks/BaseSymbolicLinks.FileSystem.cs Outdated Show resolved Hide resolved

jozkee reviewed Jun 18, 2021

View reviewed changes

src/libraries/Common/tests/TestUtilities/System/IO/FileCleanupTestBase.cs Outdated Show resolved Hide resolved

jozkee reviewed Jun 19, 2021

View reviewed changes

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.CreateSymbolicLink.cs Outdated Show resolved Hide resolved

danmoseley reviewed Jun 22, 2021

View reviewed changes

src/libraries/Common/src/Interop/Windows/Kernel32/Interop.CreateSymbolicLink.cs Outdated Show resolved Hide resolved

danmoseley reviewed Jun 22, 2021

View reviewed changes

src/libraries/System.Private.CoreLib/src/Resources/Strings.resx Outdated Show resolved Hide resolved

jozkee mentioned this pull request Jun 22, 2021

[FileStream] handle UNC and device paths #54483

Merged

tmds reviewed Jun 22, 2021

View reviewed changes

src/libraries/Common/src/Interop/Unix/System.Native/Interop.ReadLink.cs Outdated Show resolved Hide resolved

jozkee requested a review from adamsitnik July 6, 2021 23:37

adamsitnik approved these changes Jul 7, 2021

View reviewed changes

jozkee added 3 commits July 7, 2021 20:38

Avoid testing the reparse point/soft link limit very precisely

6f5b99a

Fix LinkTarget invalidation logic

2d09f7e

Make returnFinalTarget no longer optional

4b5e133

Merge branch 'main' of https://github.com/dotnet/runtime into symlinks

82dc88a

Try to fix failing tests found in CI

48e1af1

Try smaller chains of links

0495f59

jozkee added 2 commits July 8, 2021 22:50

Avoid using GetTestFilePath in order to correctly compare against the…

40cb737

… real temp path Bring back previous InlineData since it wasn't the cause of the CI issue

Use chain length of 20 instead of 30, which fails in Win 1809

995ead5

adamsitnik merged commit dcce0f5 into dotnet:main Jul 9, 2021

carlossanlop deleted the symlinks branch July 9, 2021 18:33

jozkee mentioned this pull request Jul 14, 2021

Remove default value from param in ResolveLinkTarget(bool returnFinalTarget) missed in the main PR #55670

Merged

ManickaP mentioned this pull request Jul 20, 2021

[QUIC] Remove AppContext switch from S.N.Quic #56027

Merged

ghost locked as resolved and limited conversation to collaborators Aug 8, 2021

		/// Allows creation of symbolic links when the process is not elevated. Starting with Windows 10 Insiders build 14972.
		/// Developer Mode must first be enabled on the machine before this option will function.

	return targetPath == null ? null :
	return targetPath is null ? null :

Add symbolic link APIs #54253

Add symbolic link APIs #54253

Conversation

carlossanlop commented Jun 15, 2021

dotnet-issue-labeler bot commented Jun 15, 2021

ghost commented Jun 15, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carlossanlop Jun 16, 2021 • edited by jozkee Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carlossanlop commented Jun 21, 2021

hoyosjs commented Jun 21, 2021 • edited Loading

adamsitnik left a comment

Choose a reason for hiding this comment

jeffhandley commented Jul 7, 2021

jozkee commented Jul 8, 2021 • edited Loading

terrajobst commented Jul 8, 2021 • edited Loading

iSazonov commented Jul 8, 2021

bartonjs commented Jul 8, 2021

iSazonov commented Jul 8, 2021

jozkee commented Jul 8, 2021

iSazonov commented Jul 9, 2021 • edited Loading

jozkee commented Jul 9, 2021

jeffhandley commented Jul 9, 2021

carlossanlop Jun 16, 2021 •

edited by jozkee

Loading

hoyosjs commented Jun 21, 2021 •

edited

Loading

jozkee commented Jul 8, 2021 •

edited

Loading

terrajobst commented Jul 8, 2021 •

edited

Loading

iSazonov commented Jul 9, 2021 •

edited

Loading