TestContext.AddTestAttachment with long file paths

[elv1s42]

Hello!

I have some tests that create different artefacts (log files, screenshots, etc.), and sometimes the full paths of the artefacts can be longer, than 255 symbols. The artefacts are still created and published in TeamCity, but I'm facing the issue, that NUnit can't handle such file paths when I'm using TestContext.AddTestAttachment(filePath).
The problem is hidden inside the AddTestAttachment method:

            if (!File.Exists(filePath))
                throw new FileNotFoundException("Test attachment file path could not be found.", filePath);

            var result = TestExecutionContext.CurrentContext.CurrentResult;
            result.AddTestAttachment(new TestAttachment(filePath, description));

When filePath is too long, File.Exists(filePath) returns false and I'm getting the FileNotFoundException. But in reality, the file exists, and I'm able to access it.

Is there a way to bypass the File.Exists validation?

I tried to use the "\\?\" prefix as suggested by Microsoft, but it didn't help.

[elv1s42]

For now, I've implemented a workaround using Reflection to invoke internal method TestExecutionContext.CurrentContext.CurrentResult.AddTestAttachment and pass my TestAttachment instance.
Looks like an ugly solution, but it does the job for me, I'm getting my attachments with long paths saved inside NUnit test resultsxml file.

[stevenaw]

Thanks for the bug report @elv1s42 and for providing the work around to help others.
I suspect this is actually an issue with the underlying OS, but it may be possible that something can be done to work around it. It sounds like you're using Windows, but can you also confirm with version of the Nunit framework you're using?

[elv1s42]

Thank you for the quick reply!

Yes, I'm using Win 10. I reproduced the issue in a simple unit test project, created from a template in Visual Studio. The sample project has the following dependencies:

    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.3.2" />
    <PackageReference Include="NUnit" Version="3.13.3" />
    <PackageReference Include="NUnit3TestAdapter" Version="4.3.0" />
    <PackageReference Include="NUnit.Analyzers" Version="3.5.0" />
    <PackageReference Include="coverlet.collector" Version="3.1.2" />

The test loos like this:

    [Test]
    public void Test1()
    {
      var file = "log.txt"
      var folder = @"C:\very long path";
      var path = Path.Combine(folder, file);
      Console.WriteLine($"{path.Length}"); // check if the lenght is long enough
      Console.WriteLine($"{File.Exists(path)}"); // returns false for long paths
      
      TestContext.AddTestAttachment(path); //throws exception when path is too long
      Assert.Pass();
    }

This test fails with:

System.IO.FileNotFoundException : Test attachment file path could not be found.
   at NUnit.Framework.TestContext.AddTestAttachment(String filePath, String description)
   at TestProject1.Tests.Test1() in C:\TestProject1\UnitTest1.cs:line 22
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

[elv1s42]

So in general the issue is in the way File.Exists(filePath) works for long paths, but it would be nice if the NUnit could handle this somehow. For example, one of the possible solutions is to add the ability to disable the file validation in TestContext.AddTestAttachment.

[stevenaw]

Thanks @elv1s42

I've been doing a bit of experimenting and I've noticed the following:

• I'm able to reproduce this with a basic console app (no NUnit) on Windows using .NET Framework 4.7.2 but not on .NET Core3.1, .NET6, or .NET7
• If a file does pre-exist at a path longer than 260 chars, a .NET Framework app can check existence if referenced by an absolute path prefixed with "\\?\". Interestingly, a relative path doesn't work with "\\?\".

Assuming you're using .NET Framework and passing this as a relative path, can you try switching it up to an absolute path to see if the prefix helps there?

[elv1s42]

In my case, File.Exists(filePath) still returns false with the absolute path with the "\\?\" prefix.
The file exists on the disk, and I'm able to open it in Notepad++.
I've tried to set up different TargetFramework (net5.0, net6.0, net7.0), but the behaviour is the same for all of them.
Also, I've checked that long paths are enabled (I'm using Windows 10 Pro):

[stevenaw]

Curious. Thanks for confirming @elv1s42 appreciate the feedback.
I'd forgotten to share my repro earlier, but I can do it later today. Hopefully you can confirm if it works for you or not, which could help us get to the bottom of this

[stevenaw]

@elv1s42 Can you let me know if the following works for you, as well as the runtime version (net472, net6, etc) you originally attempted to run your tests against? The below should make a new directory and file in %TEMP% and then attempt to add it as a test attachment via an absolute path. When compiled against .NET Framework it should also prepend "\\?\".

internal class Issue4353
    {
        private string _path;

        [SetUp]
        public void Setup()
        {
            var pathWithEnv = @"%TEMP%\NUnitTest4353";
            var folder = Environment.ExpandEnvironmentVariables(pathWithEnv);

            Directory.CreateDirectory(folder);

            var fileNameLength = (260 - folder.Length) + 3;
            var file = new string('A', fileNameLength) + ".txt";

            _path = Path.Combine(folder, file);

#if NETFRAMEWORK
            // Work around for long paths on netfx
            if (_path.Length > 260 && Path.IsPathRooted(_path))
                _path = $@"\\?\{_path}";
#endif

            File.WriteAllText(_path, "Hello World");
        }

        [Test]
        public void Test1()
        {

            TestContext.AddTestAttachment(_path); //throws exception when path is too long

            //Assert.Pass();
        }

        [TearDown]
        public void TearDown()
        {
            File.Delete(_path);
        }
    }

[elv1s42]

This is really stupid, but I was able to find out why the prefix didn't work for me. When I was doing experiments with the long paths, I renamed the file so that the full path fill be 259 characters. Then, I simply created a copy of this file (using Ctrl+C / Ctrl+V), which should produce the file named <old_name> - Copy.txt. Then in the unit test code, I modified the file name by typing - Copy in the end of the file name and did all the experiments mentioned above.
What I missed, is that my file name length was close to 260 characters, so when I created a copy of this file, Windows trimmed the part of the original name, so that the total file name length will be shorter than 260 characters.
So in reality, I did all my experiments with the "\\?\" prefix and different target frameworks for the file that didn't exist on the disk 😭😭😭
Sorry for wasting your time by providing the wrong information.

Now I can confirm that long paths are working fine for net5.0, net6.0, net7.0.
For .net framework 4.7.2 long paths are working only with the "\\?\" prefix and full paths.

So in general, it looks like your fix with the prefix can be used inside TestContext.AddTestAttachment

#if NETFRAMEWORK
            // Work around for long paths on netfx
            if (_path.Length > 260 && Path.IsPathRooted(_path))
                _path = $@"\\?\{_path}";
#endif

[stevenaw]

Not a problem @elv1s42 ! This is an area I haven't had much practical experience in so I was glad for the opportunity to investigate. I'm glad it was a simple discovery on your end.

As far as inclusion into the framework, I'd be curious to hear the thoughts of another @nunit/framework-team member. Two concerns I'd have are:

• Can it be done in a consistent way that all netfx consumers can use it
• Can it be done in a cross-platform safe way

I suspect both are likely fairly easy to achieve. As an open question: I don't know if we'd want to avoid writing the \\?\ into the results file to avoid potential cross-OS issues, or alternately if it would be required to write it out for a netfx-based parser to be able to process it. Perhaps it's safest to just prepend it if needed for the File.Exists() check and then write the unmodified originally supplied path out to the results file

[stevenaw]

I'm marking this as a good first issue.

It sounds like we want to modify this File.Exists() check here:

nunit/src/NUnitFramework/framework/TestContext.cs

Lines 372 to 373 in 3a35f8c

	if (!File.Exists(filePath))
	throw new FileNotFoundException("Test attachment file path could not be found.", filePath);

On .NET Framework only to prepend \\?\ to the existence check if the path if too long (see #4353 (comment)). We'd want to leave filePath unmodified for when instantiating the TestAttachment class a few lines below.