Path.GetFullPath no longer resolves long file paths

[nmoinvaz]

We have unit tests that ultimately checks to see that Path.GetFullPath returns the long file path if given a shortened path. These no longer work when running dotnet test with AltCover. It doesn't translate the shortened path to the long file path.

I've tried to break it down into an easy test you can start with:

var currentPath = Directory.GetCurrentDirectory().EnsureEnding(Path.DirectorySeparatorChar);
Directory.CreateDirectory(currentPath + "longdirectoryname/");
var actualPath = Path.GetFullPath(currentPath + "longdi~1/");
Assert.IsTrue(string.Compare(currentPath + "longdirectoryname/", actualPath) == 0);
Directory.Delete(currentPath + "longdirectoryname/");

I opened this ticket because I assumed it might be something related to this, but I don't know enough to be certain: https://github.com/SteveGilham/altcover/blob/f6113af811876692b2de426b42fec5a608ddb6d7/MCS/Program.fs#L07-L10

[SteveGilham]

Thank you for the repro code. At the moment I'll make no guesses as to what is going on.

The section of code you quote is from the executable to drive an old version of the Mono C# (hence M CS) compiler library, which I use to create test data with .mdb symbols; it's for backward compatibility testing, and not part of the actual instrumentation process, so is likely a red herring.

[SteveGilham]

Having slept on the issue, the first thing that occurs to me is to validate an assumption and ask what happens with

Directory.CreateDirectory(currentPath + "longdirectoryname/");
Assert.IsTrue(Directory.Exists(currentPath + "longdi~1/")); // is that the actual short name??
var actualPath = Path.GetFullPath(currentPath + "longdi~1/");

and also P/Invoke GetShortPathName from kernel32.dll to find out what's really happening here.

[SteveGilham]

Interesting. I run this test program as-is (altcover not used)

module TestProject1

open NUnit.Framework
open System
open System.IO
open System.Runtime.InteropServices
open System.Text

[<DllImport("kernel32.dll", CharSet = CharSet.Auto)>]
extern int GetShortPathName(
                 [<MarshalAs(UnmanagedType.LPTStr)>]
                   string path,
                 [<MarshalAs(UnmanagedType.LPTStr)>]
                   StringBuilder shortPath,
                 int shortPathLength
                 )

[<SetUp>]
let Setup () =
    ()

[<Test>]
let Test1 () =
  let basePath = Directory.GetCurrentDirectory()
  Assert.That(basePath, Does.Not.EndWith("\\"))
  Assert.That(basePath, Does.Not.EndWith("/"))
  let currentPath = basePath  + "\\"
  Assert.That(currentPath, Does.EndWith("\\"))
  printfn "CurrentPath %A" currentPath
  let longname = currentPath + "longdirectoryname/"
  let longdir = Directory.CreateDirectory(longname)
  printfn "longdir %A" longdir.FullName

  let shortPathBuilder = new StringBuilder(65000)
  GetShortPathName(longdir.FullName, shortPathBuilder, shortPathBuilder.Capacity) |> ignore
  let shortPath = shortPathBuilder.ToString();
  printfn "shortPath %A" shortPath
  let actualPath = Path.GetFullPath(currentPath + "longdi~1/")
  printfn "actualPath %A" actualPath
  Assert.Multiple (fun () ->
    Assert.That(Directory.Exists(actualPath), Is.True, "Directory not found")
    Assert.IsTrue(String.Compare(currentPath + "longdirectoryname/", actualPath) = 0, "full name mismatch"))
  Directory.Delete(currentPath + "longdirectoryname/")

and get as test output in VisualStudio

 Test1
   Source: UnitTest1.fs line 24
   Duration: 38 ms

  Message: 
Multiple failures or warnings in test:
  1)   Directory not found
  Expected: True
  But was:  False

  2)   full name mismatch
  Expected: True
  But was:  False

  Stack Trace: 
TestProject1.Test1() line 40
1)    at TestProject1.Test1@40.Invoke() in D:\Github\TestProject1\TestProject1\UnitTest1.fs:line 41
Assert.Multiple(TestDelegate testDelegate)
TestProject1.Test1() line 40
2)    at TestProject1.Test1@40.Invoke() in D:\Github\TestProject1\TestProject1\UnitTest1.fs:line 42
Assert.Multiple(TestDelegate testDelegate)
TestProject1.Test1() line 40

  Standard Output: 
CurrentPath "D:\Github\TestProject1\TestProject1\bin\Debug\net8.0\"
longdir "D:\Github\TestProject1\TestProject1\bin\Debug\net8.0\longdirectoryname\"
shortPath "D:\Github\TestProject1\TestProject1\bin\Debug\net8.0\longdirectoryname\"
actualPath "D:\Github\TestProject1\TestProject1\bin\Debug\net8.0\longdi~1\"

This may be a result of one or other of the settings to remove the windows 255-character path length restriction on my Windows 11 dev machine (similarly dir /X at a cmd prompt shows no 8.3-style names).

[SteveGilham]

Digging out an old laptop that does show 8.3 names, and changing the penultimate line to

    Assert.That(String.Compare(currentPath + "longdirectoryname\\", actualPath) = 0, "full name mismatch"))

does make the test pass.

So, can we ascertain whether 8.3 names are working at all on your test machine?

[SteveGilham]

Adding the console log from the run that succeeded, which I forgot to do this morning -

PS C:\Users\steve\source\repos\TestProject1\TestProject1> dotnet test /p:AltCover=true /p:AltCoverLocalSource=true
  Determining projects to restore...
  All projects are up-to-date for restore.
  TestProject1 -> C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\TestProject1.dll
  Creating folder C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\
  Instrumenting files from C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\
  Writing files to C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\
     => C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\TestProject1.dll

  Coverage Report: C:\Users\steve\source\repos\TestProject1\TestProject1\coverage.xml

      C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\TestProject1.d
  ll
                  <=  TestProject1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
  Settings Before:
  Settings After: C:\Users\steve\AppData\Local\Temp\tmpquhfg5.altcover.runsettings
Test run for C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\TestProject1.dll (.NETCoreApp,Version=v8.0)
Microsoft (R) Test Execution Command Line Tool Version 17.9.0 (x64)
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
CurrentPath "C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\"
longdir "C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\longdirectoryname\"
shortPath "C:\Users\steve\source\repos\TESTPR~1\TESTPR~1\bin\Debug\net8.0\__INST~1\LONGDI~1\"
actualPath "C:\Users\steve\source\repos\TestProject1\TestProject1\bin\Debug\net8.0\__Instrumented_TestProject1\longdirectoryname\"

Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: 417 ms - TestProject1.dll (net8.0)
  ... C:\Users\steve\source\repos\TestProject1\TestProject1\coverage.xml.0.acv (124b)
  22 visits recorded in 00:00:00.0111442 (1,974 visits/sec)
  A total of 22 visits recorded
  Coverage statistics flushing took 0.05 seconds
  Visited Classes 2 of 3 (66.67)
  Visited Methods 3 of 4 (75)
  Visited Points 21 of 22 (95.45)
  Visited Branches 0 of 4 (0)
  Maximum CRAP score 2

  ==== Alternative Results (includes all methods including those without corresponding source) ====
  Alternative Visited Classes 2 of 3 (66.67)
  Alternative Visited Methods 4 of 5 (80)
  Alternative maximum CRAP score 2

[nmoinvaz]

The section of code you quote is from the executable... for backward compatibility testing, and not part of the actual instrumentation process, so is likely a red herring.

Sorry about that then, I thought this might have been the culprit, because it stopped working after adding AltCover to the project.

So, can we ascertain whether 8.3 names are working at all on your test machine?

What I am seeing is that 8.3 names are working on NTFS, but not on ReFS (dev drive). But it appears that ReFS removes 8.3 filenames, so I suppose that is expected. I need to double check my CI to see there is no problem there where I originally spotted the problem.

[nmoinvaz]

My issue on the CI ended up being something else. It was running all projects using dotnet test mysolution.sln and I had to implement this: https://dasmulli.blog/2018/01/20/make-dotnet-test-work-on-solution-files/

Thank you for your help on my issue report!!