MockFileInfo doesn't throw an exception when created with a too-long path (260+ characters)

[AlexanderPruss]

A FileInfo object throws an exception if it's created from an invalid path; MockFileInfos currently only throw this exception later, once their internal Path instance is called.

[AlexanderPruss]

Yet another one: #193

[jpreese]

Confirmed an issue. I don't know if I'm a huge fan of calling the underlying implementation as a workaround, but definitely an issue.

[hangy]

There might be some gotchas as the exception

• should be thrown for more than 260 chars and .NET older than 4.6.2 or Windows long paths disabled
• should not be thrown if on .NET 4.6.2+ and long paths enabled (https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/)
• should not be thrown on .NET Core

The .NET core repo has some interesting path tests for those scenarios, and feature detection.

[rkoeninger]

There also the issue of handling the 4-character unicode path prefix (\\?\), which allows for longer paths. It's referenced throughout the System.IO framework code. I don't understand it in detail, but you can read about it here: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file

I've never seen anyone use it in practice, so it might not be worth worrying about.

[hangy]

Does the \\?\ syntax work for you? I just tried it in csi, and it threw an Exception. I think that this is probably not accessible from .NET ..?

> System.IO.Directory.EnumerateFiles(@"\\?\D:\")
Illegal characters in path.
  + System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(string)
  + FileSystemEnumerableIterator<TSource>..ctor(string, string, string, System.IO.SearchOption, SearchResultHandler<TSource>, bool)
  + System.IO.Directory.EnumerateFiles(string)
> using System.IO.Abstractions.TestingHelpers;
> var mfs = new MockFileSystem();
> mfs.Path.GetFullPath(@"\\?\D:")
"\\\\?\\D:"

Your link does pose another interesting question for this library, though: How do you want to cope with filenames that are forbidden on an OS? This seems to be another case that the abstraction accepts, but .NET fails on:

> mfs.AddFile("COM1", new MockFileData("dummy"))
> mfs.File.ReadAllText("COM1")
"dummy"
> System.IO.File.Create("COM1")
FileStream will not open Win32 devices such as disk partitions and tape drives. Avoid use of "\\.\" in the path.
  + System.IO.FileStream.Init(string, System.IO.FileMode, System.IO.FileAccess, int, bool, System.IO.FileShare, int, System.IO.FileOptions, Microsoft.Win32.Win32Native.SECURITY_ATTRIBUTES, string, bool, bool, bool)
  + System.IO.FileStream..ctor(string, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, int)
  + System.IO.File.Create(string)

[rkoeninger]

Hmmm... I get the same error. If I try a relative path like @"\\?\.", it says that's an invalid UNC path.

You can see the prefix referenced in the reference source and I saw the same thing when I decompiled the reference assemblies I'm using.

So probably not worth worrying about \\?\.

[jpreese]

I'd personally wouldn't worry about it, especially forbidden filenames. I don't want to get into a situation where we're trying to cover every little corner case and introducing a lot of branching on Windows vs. Unix.

It would just be a nightmare to maintain if we get that granular. @fgreinacher @robkeim

[fgreinacher]

That’s really corner-case behavior, sometimes even depending on what the OS does. So I’d also say let’s ignore it.

[jpreese]

Alright I'm going to close this out.