ParsePath not working for UNC path in IS 2014

[mpa109]

InstallScript Project

I have a piece of code where I'm pulling the share name of a UNC path using ParsePath. i.e.:

szUNCPath = "\\\\MachineName\\FolderName";
ParsePath(szShareName, szUNCPath, FILENAME);  //using FILENAME since IS just pulls the value after the last slash as the value
MessageBox (szShareName, SEVERE);

The result is an empty value for szShareName.

I've been using this piece of code in the same project since probably IS12 (that's 12, not 2012), and have upgraded versions of IS every year (except 2013), and this never presented a problem, szShareName would return "FolderName" in the value. Now, in IS 2014, it's not working.

I've tried passing other operators in ParsePath (DIRECTORY, FILENAME_ONLY, PATH), and the only one that returns a value is PATH, which is not helpful.

Also tried:

GetDir(szUNCPath, szShareName);

but got the same results.

I can bypass by using some StrFind and StrSub functions, but that's not what I want to do, and want to know why this isn't working all of a sudden.

Any thoughts?

[MichaelU]

Looking at the help topic for ParsePath I'm not convinced the behavior you expect matches the documented behavior. It looks like for a path of the format \\server\share\dir\file.ext, the DISK is \\server\share, the DIRECTORY is \dir\ and the FILENAME is file.ext. This would indicate for a shorter path of just \\server\share, the DISK would remain the same, but the DIRECTORY and FILENAME would be empty.

However I would typically not expect us to have changed this behavior, so it sounds like we need to assess whether the behavior was buggy, the docs were buggy, or if the scenario was what changed. Is there any variability in the way you acquire the path you pass to ParsePath, or have you verified simple hardcoded strings in multiple versions of InstallShield?

[mpa109]

First, I should amend my original statement. My code did actually take into account the file name and extension by adding a fake extension.

The UNC path is retrieved from a database table, in the format "\\MachineName\FolderName". I append a ".tmp" to the end to make it look like a file, and then use the "FILENAME_ONLY" to retrieve the FolderName value (which is the UNC share name that I'm looking for).

The UNC path is passed into a function and the local path

		szUNCTemp = szUNCPath + ".tmp"; //create a fake filename for ParsePath
		ParsePath(szShareName, szUNCTemp, FILENAME_ONLY);

This worked fine up through IS2012, same code not working when I upgraded the project into IS2014.

I can recreate using hardcoded strings as well. However, if I change the scenario, I get different results for IS2014 and IS2012 (same code used in both versions):

		//A
		szUNCPath = "\\\\MachineName\\FolderName";
		szUNCTemp = szUNCPath + ".tmp"; //create a fake filename for ParsePath
		ParsePath(szShareName, szUNCTemp, FILENAME_ONLY);
		MessageBox("ORIGINAL\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
		//IS2014 returns szShareName = ""
		//IS2012 returns szShareName = "FolderName"
		
		//B
		szUNCPath = "\\\\MachineName\\FolderName";
		szUNCTemp = szUNCPath; //no fake filename
		ParsePath(szShareName, szUNCTemp, DIRECTORY);
		MessageBox("DIRECTORY (no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
		//IS2014 returns szShareName = ""
		//IS2012 returns szShareName = ""
		
		//C
		szUNCPath = "\\\\MachineName\\FolderName";
		szUNCTemp = szUNCPath; //no fake filename
		ParsePath(szShareName, szUNCTemp, FILENAME);
		MessageBox("FILENAME (no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
		//IS2014 returns szShareName = ""
		//IS2012 returns szShareName = "FolderName"
		
		//D
		szUNCPath = "\\\\MachineName\\FolderName";
		szUNCTemp = "\"" + szUNCPath + "\""; //surround with quotes
		ParsePath(szShareName, szUNCTemp, DIRECTORY);
		MessageBox("DIRECTORY (surrounded by quotes, no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
		//IS2014 returns szShareName = "\"\\\\MachineName\\"
		//IS2012 returns szShareName = "\"\\\\MachineName\\"
		
		//E
		szUNCPath = "\\\\MachineName\\FolderName";
		szUNCTemp = "\"" + szUNCPath + "\""; //surround with quotes
		ParsePath(szShareName, szUNCTemp, FILENAME);
		MessageBox("FILENAME (surrounded by quotes, no fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
		//IS2014 returns szShareName = "FolderName\""
		//IS2012 returns szShareName = "FolderName\""

		//F
		szUNCPath = "\\\\MachineName\\FolderName";
		szUNCTemp = "\"" + szUNCPath + ".tmp\""; //add fake filename, surround with quotes
		ParsePath(szShareName, szUNCTemp, FILENAME_ONLY);
		MessageBox("FILENAME (surrounded by quotes, fake filename)\nszUNCTemp = " + szUNCTemp + "\nszShareName = " + szShareName, SEVERE);
		//IS2014 returns szShareName = "FolderName"
		//IS2012 returns szShareName = "FolderName"

So, scenario "A", the original scenario, behaves differently in IS2014 and IS2012, with IS2012 giving the results I've expected over time and throughout previous versions of IS.

Scenario "B" both return blank, which is kind of expected, as "\\\\MachineName\\FolderName" is probably considered the "DISK", there is no "DIRECTORY"

Scenario "C" returns different results, and, again, IS2012 would be the preferred, and maybe expected (?) results.

Scenario "D" returns the same results, but contains a leading quote mark for some reason.

Scenario "E" returns the same results, but contains a trailing quote mark for some reason.

Scenario "F" returns the same results "FolderName", which is what I'm looking for, but based on results for "D" and "E" this seems kind of "lucky" in that "D" and "E" pick up the leading and trailing quotes, but since this is FILENAME_ONLY, the trailing quote would be at the end of the file extension.

Just find this very odd, as I can't imagine the ParsePath function underwent many changes from IS2012 and IS2014.