UNC paths from local paths

I needed to get an UNC path from a local path. I was searching the MSDN and the Internet to get information about this, but I didn't find anything. I did find posts requesting a procedure to solve this problem, so maybe this code can be useful.

The solution I found is tricky, perhaps too much tricky, but it seems to work properly. It has been tested in Windows 9x and Windows NT 4.0. The idea is to get the name of the shared resources and look for its real path in the registry (the keys are different in Win9x and NT). When we have the path, we check if the local path that we want to translate to UNC is a subtree of the resource path. If not, we continue the process until no more shared resources are found (or until the UNC path is found). This approach could be also used to solve the inverse problem, how to get a local path from an UNC path.

This procedure has been implemented in a class, CUNC, which has just one public method:

bool GetUNCFromLocalPath(LPCTSTR localPath, CString *uncPath);

In order to use this class, just add the files to your project and instantiate a CUNC object when needed:

void Foo() {
  CFileDialog dlg(TRUE);
  if (dlg.DoModal() == IDOK) {
    CString filename;
    CUNC unc;
    if ( unc.GetUNCFromLocalPath(dlg.GetPathName(),
         &filename)) {
      // ...
    }
  }
}

Downloads

Download source - 3Kb


Comments

  • help please

    Posted by greenjade800 on 04/23/2004 03:49pm

    Do you know how to get UNC when the remote path don't have a local drive letter? For example, server published the software. It is showing on the add/remove program.

    Reply
  • Great job man !!!

    Posted by Legacy on 11/14/2003 12:00am

    Originally posted by: Kreelin

    Well done Manuel !!!
    This is exactly what i need.

    Reply
  • FIX for W9x

    Posted by Legacy on 07/30/2002 12:00am

    Originally posted by: Pascal

    Nice work despite it doesn't work as-is with W9x (nor with the contribution of HJ). I found TWO fixes to make it run fine.

    1 - The problem comes when you call GetLocalHostName, because the 'gethostname' function returns the name of Host as it stands in the DNS tab of TCP-IP configuration. With W9x you can put there nothing, or something stupid (e.g. 'asdf'). And finally that can't be used.

    Instead of that it's better to call '::GetComputerName' function, which returns the name of the computer as it is seen from the network.

    2 - If the path you want to parse is a local root path (C:\hello.txt - that gives you are looking for 'C:'), then in the TryResource function it will NEVER correspond to the resource, as this one will be 'C:\'. So you have to add a couple of lines:

    if(localPath.GetLength()==2 && localPath[1]==':')
    localPath += "\\";

    return localPath.Find(*pathResource) == 0;


    And it works in all cases (as far as I can guess).

    Pascal

    Reply
  • Bug fixed when network mapping

    Posted by Legacy on 11/24/2001 12:00am

    Originally posted by: Hong Jun

    The CUNC class is of great works, but I found a bug when 
    
    localpath point to a mapped driver letter(eg. z:), the
    founction return FALSE! So I add some code on
    GetUNCFromLocalPath founction:

    bool CUNC::GetUNCFromLocalPath(LPCTSTR localPath, CString *uncPath) {
    bool ret = false;
    CString local = localPath;

    DWORD cbBuff = MAX_PATH; // Size of Buffer
    TCHAR szBuff[MAX_PATH]; // Buffer to receive information
    UNIVERSAL_NAME_INFO * puni = (UNIVERSAL_NAME_INFO *) &szBuff;


    uncPath->Empty();

    if (local.Left(2) == "\\\\") {
    *uncPath = local;
    ret = true; // It's UNC already
    }
    else if(WNetGetUniversalName(localPath,
    UNIVERSAL_NAME_INFO_LEVEL,
    //
    //The structure is written to this block of memory.
    //
    (LPVOID) &szBuff,
    &cbBuff) == NO_ERROR){
    //uncPath->Format("%s", szBuff);
    *uncPath = puni->lpUniversalName;
    ret = true;
    }
    else{
    if (SearchUNCForPath(local, uncPath))
    ret = true;
    }

    return ret;
    }

    now it works for both mapped drive and shared folder.

    Reply
  • RE: Existing windows SDK function

    Posted by Legacy on 08/04/2001 12:00am

    Originally posted by: M. Escribano

    Yes, but WNetGetUniversalName() only works if there is a network mapping. If the remote path has not a local drive letter, it doesn't work.
    MAPI also has a ScLocalPathFromUNC()function, but it warns that could not be available in future versions.

    Reply
  • Existing windows SDK function

    Posted by Legacy on 07/26/2001 12:00am

    Originally posted by: Oren Recht

    A windows SDK fonction converts local path to UNC :
    
    WNetGetUniversalName

    But it works only on NYT and 2000 platforms

    Howerver you class is interresting to get local path from UNC.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Today's agile organizations pose operations teams with a tremendous challenge: to deploy new releases to production immediately after development and testing is completed. To ensure that applications are deployed successfully, an automatic and transparent process is required. We refer to this process as Zero Touch Deployment™. This white paper reviews two approaches to Zero Touch Deployment--a script-based solution and a release automation platform. The article discusses how each can solve the key …

  • On-demand Event Event Date: October 29, 2014 It's well understood how critical version control is for code. However, its importance to DevOps isn't always recognized. The 2014 DevOps Survey of Practice shows that one of the key predictors of DevOps success is putting all production environment artifacts into version control. In this webcast, Gene Kim discusses these survey findings and shares woeful tales of artifact management gone wrong! Gene also shares examples of how high-performing DevOps …

Most Popular Programming Stories

More for Developers

RSS Feeds