.Net Core Directory.GetFiles() operates webDav path

[MaChao9914]

When .net core system.io Directory.GetFiles() operates \\xxx.xx.xx.x@88\DavWWWRoot\Doclib, there will be an extra'\0' at the end of the file path string, such as "\\xxx .xx.xx.x@88\DavWWWRoot\DocLib\TeamViewer_Setup.exe1\0", and then use File.ReadAllBytes() to read content and an error occurred: System.ArgumentException:“Illegal characters in path. ”, but this will not happen in the .net framework.

[carlossanlop]

Can you verify if that extra character at the end is a folder named 0, or is it an actual null character? If it's a null character, then .NET Core and .NET 5 do not allow them in paths. We even have an API that returns illegal path characters for you: Path.GetInvalidFileNameChars

Unix has these illegal characters:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/Path.Unix.cs

Line 12 in 1d9e50c

public static char[] GetInvalidFileNameChars() => new char[] { '\0', '/' };

Windows has these illegal characters:

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

Lines 20 to 27 in 1d9e50c

	public static char[] GetInvalidFileNameChars() => new char[]
	{
	'\"', '<', '>', '|', '\0',
	(char)1, (char)2, (char)3, (char)4, (char)5, (char)6, (char)7, (char)8, (char)9, (char)10,
	(char)11, (char)12, (char)13, (char)14, (char)15, (char)16, (char)17, (char)18, (char)19, (char)20,
	(char)21, (char)22, (char)23, (char)24, (char)25, (char)26, (char)27, (char)28, (char)29, (char)30,
	(char)31, ':', '*', '?', '\\', '/'
	};

[hanaimin]

@carlossanlop @MaChao9914
hello guys,
The same issue occurs when .netcore(3.1/5.0) accesses microsoft sharepoint webdav. .netcore system.io api return wrong file/folder pathes with char '\0'. But the similar test result using .net framework or java is correct.

Then I test using .netcore System.IO.Directory.GetFiles() api to access milton webdav (the thirdpart webdav component), the same issue occors.

So maybe the problem is special for .netcore + webdav.

[MaChao9914]

@carlossanlop
I verified that there is no folder named 0 or invalid path characters exist. and the webdav path "\\xxx.xx.xx.x@88\DavWWWRoot\Doclib" can be used normally in the windows explorer.

[lscorcia]

Same issue here. Blocking the migration to .net5 of some batch processes that use SharePoint WebDav folders to publish information on external websites. This is the Directory.GetDirectories call on a WebDav path:

And this is what is returned:

Note the two "." and ".." subfolders that were not returned under the .net full framework and the \0 (an actual null character) at the end of each directory name.

[lscorcia]

I tried source-stepping in the .net code and it seems like the error comes directly from the file system enumeration process:

Even if the file name is exactly one character long, the FileNameLength property returns the value 4.
Looking at the Interop.FILE_FULL_DIR_INFORMATION class, the FileName is actually computed from "the initial byte returned by Win32 API + (the reported length of the string / sizeof(char))":

runtime/src/libraries/Common/src/Interop/Windows/NtDll/Interop.FILE_FULL_DIR_INFORMATION.cs

Lines 56 to 57 in 57bfe47

	private char _fileName;
	public unsafe ReadOnlySpan<char> FileName { get { fixed (char* c = &_fileName) { return new ReadOnlySpan<char>(c, (int)FileNameLength / sizeof(char)); } } }

MSDN for the FILE_FULL_DIR_INFORMATION struct (https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_full_dir_information ) does not specify whether the length is expressed in bytes or in characters. Unicode "." is 00 2E 00 00, so 4 bytes long. This seems to imply that FileNameLength is expressed in bytes and that it includes the trailing \0 - this means that the FileName ReadOnlySpan is initialized with value (4 / sizeof(char)) = 2.

This inclusion of the null terminator seems weird to me. Win32 APIs that explicitly return a string length generally don't return additional null chars at the end of the buffer. Also, I verified that it's not coming from the XML WebDav response (actually the '.' and '..' folders do not show up in there at all).

But then, why is it working on framework 4.8? Surely the Win32 API is returning the same values even on full framework - IF it is even using the same API. Unfortunately, debugging the .net framework does not lead me anywhere - the code is optimized and I can't step into it.

Maybe the actual root issue could be a bug in the WebDav client stack (i.e. the extra null byte should not be returned)? This would explain why the issue does not show up when enumerating local folders, and maybe the consequences are not visibile in fw 4.8 because it unmarshals buffers to strings instead of Spans? Maybe unmarshalling to string adds some extra processing related to null terminators?

[danmoseley]

making sure that @dotnet/area-system-io folks see above comment since I see it was noted to be blocking migration from .NET Framework.

[lscorcia]

It seems like the bug has been acknowledged at #49803 . Let's hope it gets prioritized, anyway this is now a duplicate.

[jkotas]

Closing as duplicate of #49803