6

I'm having issues with the SelectedPath property of the FolderBrowserDialog when the folder I select is on a remote server and is a symbolic link (or any kind of reparse point).

If i select a normal folder, then I get the full path returned, for example "\SERVER\folder\subfolder\thing_I_clicked_on".

However, if the folder is a reparse point, i get just "\SERVER\thing_I_clicked_on" (so it's missing the full path)

var dialog = new FolderBrowserDialog();
dialog.ShowDialog();
MessageBox.Show(dialog.SelectedPath);

Anyone come across this or have any suggestions? It doesn't appear to be permissions related, as if I know the full path i can quite happily browse to it, etc.

Andy Irving
  • 2,549
  • 1
  • 13
  • 11

3 Answers3

2

so, I've been investigating this quite a lot, and think i have an answer.

First, a bit of explanation about what I was seeing!

on server A, there is a share which contains a symbolic link to a share on server B:

\\serverA\Path\To\Folder

and the target of that is 

\\serverB\Folder

What was actually happening was, the value returned from FolderBrowserDialog.SelectedPath was \\serverB\Folder, and I was mistakenly thinking it was missing parts of the path, because the strings serverA and serverB are very similar! Sorry for misleading everyone.

I created my own wrapper following this MSDN Example and noticed that the Shell32.dll function SHGetPathFromIDList is returning the Target of the reparse point, despite the fact that the documentation says

If the pidl parameter specifies a shortcut, the pszPath will contain the path to the shortcut, not to the shortcut's target

I did notice that the path before that is the correct one though, so in my callback method when the status changed, I captured the untranslated selected path

private int FolderBrowserCallback(IntPtr hwnd, int msg, IntPtr lParam, IntPtr lpData)
        {
            switch (msg)
            {
                 case BrowseForFolderMessages.BffmSelchanged:
                     if (haveValidPath && !String.IsNullOrEmpty(displayedPath))
                                {
                                    if (IntPtr.Zero != _hwndEdit)
                                    {
                                        SelectedFullPath = displayedPath;
                                    }
        }

So the SelectedFullPath Property contains \\serverA\Path\To\Folder and SelectedPath property contains \\ServerB\Folder, which leaves me a lot to work with.

Andy Irving
  • 2,549
  • 1
  • 13
  • 11
1

How do I programmatically access the target path of a windows symbolic link must be here. Are you sure that you need exactly full path, not path to reparse point? I think you can use this path instead. "Notethat Windows does not support junctions to directories on remote shares." proof

Community
  • 1
  • 1
cdmnk
  • 189
  • 11
  • Hi - whether full or relative, i do need the whole path, which is not what i'm getting. thanks for the link - windows absolutely does allow symbolic links to remote directories though (junctions and symblic links are both reparse points but not the same): mklink /D C:\blah \\server\path\to\blah – Andy Irving Sep 17 '12 at 12:05
  • Ha! Looks like this is the answer: [link](http://blogs.msdn.com/b/oldnewthing/archive/2010/02/12/9962359.aspx) – cdmnk Sep 18 '12 at 07:27
1

Andy's answer looks like it will work except the details are missing, and I cannot figure out where to add his code snippet to the MSDN example code. I can get the "MSDN sample" code to work, just don't know where to slip in Andy's stuff.

So... for those of you like me who can't figure out what to do with the code above, (I really wish I knew what I was doing ;) here is a kind of lame workaround solution.

Use the filedialog class in lieu of the browseforfolder and set the;

  • DereferenceLinks Property = false
  • CheckFileExists = false
  • filename = a bogus default filename. (Let the user know that it doesn't matter what the file name is since they are just choosing a folder.)
  • Use either a OpenFileDialog, or SaveFileDialog.

Note that when this is done, if the user clicks on an old fashioned windows shortcut (*.lnk) it (the shortcut) will be returned as the filename, so you will have to account for that.

Hope this Helps ;) (I'll work on getting some "reputation" so I can comment on Andy's post to get the details for his answer since it looks really nice.)

RJ_
  • 11
  • 2