FZ 3.67.0 unable to open/use NTFS junction reparse points on Windows client

[hlygrail]

Previous version(s) worked fine for years, so something has changed in the latest rev. to break the parsing of NTFS junction points.

I have a media server (Plex)/storage mule with the following layout, where F: is a physical disk with a directory (HDMEDIA4) on it. F:\<other directories> are linked to that same F:\ root so they all fall under the same tree even though they're other physical drives -- F:\HDMEDIA actually points to L:\HDMEDIA on another physical disk, but NTFS junction reparse points make it all look like it's sitting under F:\. They're effectively symbolic links, except for directories only:

Directory of F:\

01/20/2020 12:47 PM <JUNCTION> HDMedia [L:\HDMedia]
12/01/2015 10:49 AM <JUNCTION> HDMedia2 [W:\HDMedia2]
12/01/2015 07:19 PM <JUNCTION> HDMedia3 [W:\HDMedia3]
04/02/2024 12:18 PM <DIR> HDMedia4
11/01/2016 11:32 AM <JUNCTION> HDMedia5 [V:\HDMedia5]
10/23/2022 05:31 PM <JUNCTION> HDMedia6 [N:\HDMEDIA6]
12/09/2017 10:56 PM <JUNCTION> Media [U:\Media]
11/05/2020 04:39 PM <JUNCTION> MusicVideo [L:\MusicVideo]

With the latest FileZilla client 3.67.0, it won't let me enter any of those junction paths, either by the GUI (clicking) or typing it into the Local site: box above the local directory tree.

On the FZ client in question, F: is a mapped network drive (mapped to F$ on the storage mule box), so for example, F:\HDMEDIA6 logically looks like this:

(local FZ client F:) --> mapped to \\<IPaddr>\F$ on LAN client --> F:\HDMEDIA6 reparse point/junction to N:\HDMEDIA6 on storage mule box

Again, this has worked consistently for a long, long time (yearssss). This has broken pretty much the entirety of using FZ to download stuff into the right paths. :/ Help?

FileZilla Client

---

Version: 3.67.0

Build information:

Compiled for: x86_64-w64-mingw32
Compiled on: x86_64-pc-linux-gnu
Build date: 2024-04-15
Compiled with: x86_64-w64-mingw32-gcc (GCC) 12-win32
Compiler flags: -O2 -g -Wall -Wextra -Wno-deprecated-copy -ffunction-sections -fdata-sections -Wno-cast-function-type

Linked against:

wxWidgets: 3.2.4
SQLite: 3.39.4
GnuTLS: 3.8.4

Operating system:

Name: Windows 10 (build 19045), 64-bit edition
Version: 10.0
Platform: 64-bit system
CPU features: sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2 aes pclmulqdq rdrnd bmi bmi2 lm
Settings dir: C:\Users\XXXXXXXXXX\AppData\Roaming\FileZilla\

[Steve Jones]

I have the same issue, i have been using filezilla for years always with the latest builds.
My website is hosted on one of my secondary internal hard drives and has a physical path of
M:\inetpub\wwwroot
Using symbolic links my website appears as
C:\inetpub\wwwroot

This mapping is replicated on other computers on my LAN and so to copy stuff from one computer to another in filezilla I would enter
C:\inetpub\wwwroot\whatever is next
on the newest build filezilla is changing this to
M:\inetpub\wwwroot\whatever is next
and in doing so causes it to display a messag that the website is below the home directory and asks me to turn off the synchronized browsing.
As a temporary measure I have had to revert to the most recent previous build

[hlygrail]

Additional (silly) information... You can actually enter SUBDIRECTORIES of a network-mapped parent junction point, either manually, by typing it into the Local site: field, or by opening the tree with the [+] box and clicking directly on a subdirectory. In other words, even though it balks at opening a top-level reparse point, FZ is apparently able to figure out the contents of said junction tree... So they...kinda, sorta work... except they don't anymore.

Seems like this should be an easy fix since it always worked previously and now only partially doesn't-work.