Windows file symbolic link resolve issue

Windows
1

Hi,

The code used in juce file
static GetFinalPathNameByHandleFunc getFinalPathNameByHandle = (GetFinalPathNameByHandleFunc) getUser32Function (“GetFinalPathNameByHandle”);
is always null (even on Windows 7)

but if I replace directly getFinalPathNameByHandle by GetFinalPathNameByHandleW and remove the if, it works just fine.

Any idea ?

Thanks !

2

I suspect there’s no actual function with this name. Instead, this is a macro that resolves to GetFinalPathNameByHandleW or GetFinalPathNameByHandleA.

It looks like this function should be available on every platform we support, so perhaps we can get rid of the dll function lookup here now.

3

I tried with GetFinalPathNameByHandleW as the string instead and it wasn’t working
Still indeed, GetFinalPathNameByHandleW is Windows Vista mininmum and juce is already at this level as I was able to just replace the function so it’s pretty safe to just call it directly.

4

Thanks, there’s a fix on the juce8 preview branch:

5

Thanks !

1 Like
6

Don’t ask me why but

If I create a Juce::File which initialized to C: this ResolveLink function will return the current folder

Weird bug

7

Maybe Windows code wants some C:/ instead of C: ?
The issue is that juce::File trims it to C: by default even if I initialized it with C:/

8

Sorry, I don’t understand the problem. Please can you provide the code you’re testing, along with the expected and actual results of running that code?

9

juce::File file(“C:”);
juce::String fileStr = file.getLinkedTarget();

You will see that fileStr is not C: but something from the path where you have launched your app

10

That’s not what I see here. If I paste the following into the CMake GuiAppExample’s MainComponent constructor, it prints “C:”:

juce::File file("C:"); 
juce::File fileStr = file.getLinkedTarget(); 
DBG (fileStr.getFullPathName());

Tested on Windows 11, building with VS2022.

11

I don’t have access to a PC this week so let me get back to you.

12

I have just checked with a vanilla JUCE 8 on my Windows 10 and I reproduced the issue.

So this maybe happens only on
Windows 10
22H2
19045.5011
Windows Feature Experience Pack 1000.19060.1000.0

with VS2019.

Could you please let me know if you encounter the issue on Windows 10 ?

13

Yes, I can repro the issue on my Windows 10 machine.

This was a bit of a head-scratcher, but I learned some new things. Specifically, Windows paths that start with a drive letter and a colon but no path separator (e.g. “C:” or “D:relative\path”) are always interpreted as relative to the “current directory” of the drive (source), which is why GetFinalPathNameByHandle sometimes ends up expanding to the entire working directory.

The reason I didn’t see the problem on my Windows 11 machine is that I have a separate “D:” drive there that I use for development. When I launched the test program on that machine, the “current directory” on the C drive was still set to the root, so the path expanded out to C:\. When I changed the demo snippet to use juce::File file("D:"); then this ended up expanding out to the program’s current working directory on that drive.

I’ve put together a potential fix for this issue, and I’ll update this thread once it’s published.

1 Like
14

Yep, the trick is that juce::File discard the trailing / even if you write juce::File file("D:/")

15

The fix is now available on the develop branch:

1 Like