'Open File Dialogue' issues

Hello,

My next issue today is that the ‘Open File’ dialogue does not follow windows’ junctions (mklink /J ). When selected the ‘destination’ appears empty (although I know that it is not!)

Note: My Seamly2D folder under C:\windows\users\\Seamly2D, has been relocated to a different location Drive D: . Seamly2D’s files are apparently correctly accessible for opening a file - BUT - if for some reason, I cross that junction back to C:, and then try to use the junction to the real location, then I see no files - I assume the ‘manual’ use of the junction breaks ‘something’.

Is this a known limitation, like for example: MAX_PATH? Have I missed ‘something’ else?

As a matter of curiosity would the Seamly2D ‘nux’ version honour ‘symlinks’?

I’m not clear what you’re saying , but it sounds like you’re saying that when you try using a junction as a relative path, it doesn’t work. Which is expected. Symbolic links don’t have that limitation on either Windows or 'nix. :salt:

:unicorn:

Well, it (the junction) does actually work when I use Open File normally - accessing the files via the Junction from C:\ to D:\ , this issue only occurs if i navigate back to a directory on C: and then try to navigate through the junction to where I was initially, and at this point, where I should be seeing the files I saw the first time, I now see an ‘empty’ folder.

Sorry if my explanations are awkward & convoluted, but this is not easy to explain otherwise.

As to ‘Junction’ vs ‘Symlinks’ usage: I was advised to use Junctions for diverse reasons, which A.I. can explain (maybe) better:

Practical advantage when linking C:\Users\\seamly2d → D:\users\\seamly2d

Why a junction is often the better choice: It is directory-only, matching the use case exactly. It is highly compatible with Windows shell, Explorer, legacy APIs, and user-profile related paths. It works across drives without special permissions. It avoids the extra complexity of symlink security checks. Many Windows components treat junctions as “real folders,” reducing the chance of unexpected behavior.

A symlink might be preferred when : Linking to network paths. If you need relative paths. Linking files, not just directories.