The "smbclient" tool fails to follow MS Dfs links properly if those links refer to more than just a server and share. According to the MS docs on Dfs, links can include additional path components after the share. To verify that links can contain additional directory levels, look at the very last section of this document:
It shows the "dfscmd /map" command taking a second argument of the form:
As an example, we have a Dfs link in our environment that refers to:
The smbclient tool gets seriously confused by the last component.
I was able to create a patch against 3.0.12 that fixes the problem. (Contact me if it's of interest to you.) The source/libsmb/clidfs.c function split_dfs_path() needs to return not only server and share but also the optional path. If a non-null path is returned, cli_resolve_path() needs to copy it to the front of the current directory variable, targetpath.
I've verified that the bug still exists in 3.0.21c. I was unable to locate the equivalent functionality in the 4.0 sources in the time that I have available.
Joseph Jackson, Carnegie Mellon University.
This bug is related if not the same as bug report #3651
Can you check out this following thread and let me know if you can help by sharing your code plz ?
Hi, I based a patch on the comments to this thread and attached it to bug 3651.
Joseph, do you want to compare it to your own patch? I have no objection to retracting my patch so you can submit your's since obviously you created your patch months before mine. Cheers, Andrew
(In reply to comment #3)
Andrew - Thank you thank you. If this works, lemme buy you a beer. I have been knocking these doors for while now with no response from any one... I will try this pronto and will let you know..
This bug should be closed since bug 3651 has also been fixed by check-in 21133.
Closed as per submitters request.