FileZilla Client 3.9.0.2 not expanding/browsing DFS shared drives

[er1c]

FileZilla Client 3.9.0.2 not expanding/browsing DFS shared drives,
3.9.0.1 displays them fine, update 3.9.0.2 does not. Instead, one will see the shared drive and the root DFS namespace links but cannot browse further down then the root name spaces.

As in, the shared drive will display only 1 level down, still within DFS links, not even to the next level of DFS links, and not any further, thereby rendering them non-useable.

I've tried this on XP, Win 7, and Win 8.1. Downgrading to 3.9.0.1 resolved this issue.

I did not take a screenshot before downgrading, all you would see is that the folders have no + (PLUS symbol) next to them in the local site view, and that you can not click any further in the pane below. Right clicking and hitting "open" says "no program associated".

Same issue on multiple users machines.

Also, un-related, but SourceForge has been serving virsues up on the auto-download links and has infected machines here, I still see it offering 724K instead of the 5+MB installer for FileZilla, you may want to look into this as people are trying to download your client and ending up with malware and viruses.

Thanks!

[er1c]

This is high priority at least, because any environment with DFS drives may be at risk, requiring a downgrade or direct mapping of a DFS share, visibility/rights permitting. What good is seeing the top level of your share if you need to go several links down. Not very. Unusable for those folders meaning individuals could be copying files over to other drives to be able to access/upload or download to that folder in FileZilla. Thus this problem could be creating increased network traffic and storing of data on different than intended drives. There are other considerations, but I hope this makes it clear this is not a little issue as there are likely thousands of users who use DFS shares.

I had thought I would've seen some kind of acknolwedgement or comment on this ticket by now.

[Tim Kosse]

I have no problems browsing network shares with FileZilla 3.9.0.2, it's working just as it used to in 3.9.0.1 and earlier.

[er1c]

Hi codesquid,

Not just network shares, but network shares using AD DFS. Yes???

[er1c]

FileZilla is not working with a DFS file share in our enviornment that works just fine in every other way.

[er1c]

And another DFS share only shows the first folder.

[Tim Kosse]

I do not have access to an AD DFS. Can you please provide access to such a system for testing or at least describe the precise technical differences between an AD DFS and an ordinary filesystem?

[Tim Kosse]

Am I correct in the assumption that DFS is actually nothing else than a collection of reparse points?

[er1c]

It is different.
Reparse points are like symbolic links.

Traditional file shares,associated with a single server, have SMB paths of the form
<SERVER>\<path>\<subpath>. Domain-based DFS file share paths are distinguished by using the domain name in place of the server name, in the form
<DOMAIN.NAME>\<dfsroot>\<path>. When a user accesses such a share, either directly or by mapping a drive, their computer will access one of the available servers associated with that share, following rules which can be configured by the network administrator. For example, the default behaviour is that users will access the closest server to them; but this can be overridden to prefer a particular server.

In our case, we have root, then dfs links by location or by business unit, under offices some big locations are DFS'd but resides on separate clusters. The smaller locations are just normal shares.

FileZilla client last version works fine. Downloading the new client, breaks DFS functionality.

[Tim Kosse]

It appears that DFS is indeed nothing more than a collection of reparse points.

Reparse point handling will be improved in the next version of FileZilla. Please reopen this ticket should the issue persist in future versions.

[er1c]

Hi codesquid,

It was working fine in the last version of FileZilla, so likely something was changed, degraded or removed to now require fixing. Do you not think that is a bit odd?

Also, while similar, I am not so sure they are the same as reparse points. Replicating reparse points is a discussed issue for AD DFS.

I talked with a colleague here and his opinion on that matter:

Well, the strange thing is that they are reparse points and they aren't.
Symlinks and DFS links are both based on the FS construct in NTFS of the reparse point, the difference is where the destination is resolved. Symlinks are resolved by the machine that hosts the volume. DFS links are a reparse point that is resolved by the client but the volume manager queries AD for the metadata that is usually provided by the filesystem. Make sense? MS doesn't document this behavior very clearly on MSDN and in fact they have a lot of contradictory info up there, this is the partially documented behavior that I've observed.

[Tim Kosse]

Have you tried FileZilla 3.9.0.3 yet?

Also, while similar, I am not so sure they are the same as reparse points. Replicating reparse points is a discussed issue for AD DFS.

I managed to create a test environment using Samba as DFS root on my NAS. All directories mapped to third-party shares show up as reparse points on the client machine.

[er1c]

Can you test running FileZilla client (for windows) in an AD environment browsing a DFS share? (more than just root or one level down)? I wouldn't think it's just us.

[Tim Kosse]

Have you tried FileZilla 3.9.0.3 yet?

Can you test running FileZilla client (for windows) in an AD environment browsing a DFS share?

No. I don't use AD.

[Bruno Ramos]

Could you please test with the latest version (3.9.0.3) and check if you still have the problem?

[er1c]

Yes, I thought I commented here a while back but I did not.

This is fixed/corrected in 3.9.0.3.

Thanks,
Eric