Network Paths

[athomsen]

I need to run programs from a UNC path. Due to reasons that I will not go into using mapped drives is not a viable solution. I started digging into the code to figure out why UNC paths do not work. Below is what I came up with to solve the problem but I would like some input because it seems to easy of a fix. I must be missing something.

Line 98 in configwizard.js is: txt = txt.replace(/\\\\/g,"\\").replace(/\\/g,"\\\\");

Line 122 in generate.js is: rs = rs.replace(/\\\\/gi, "\\");

I changed Line 98 to this: txt = txt.replace(/\\/g,"\\\\");

I commented out line 122 entirely.

UNC paths work and everything else seems to function as well but I am guessing that these lines were there for a reason. So, what am I missing?

[Grizzly_MV]

That's exactly what I had to do here to make it work with network path.

I tried it with network path, local path and the variables supported by WPI and all of them seemed to work fine.

So, I guess those lines were there for a specific purpose, but can't figure it out.

Maybe the developper of WPI will have an answer? :-)

if you don't map a drive, the network path will start with \\ and the string function was replacing it with a \ so a string like this:

\\domainname\servername\sharename

was replaced by the function to:

\domainname\servername\sharename

which of course was giving a path not found error. By doing these 2 lines changes in the code, it keep the line with the \\ at the beginning of the line which is required for a network path.

I'm just saying this because I think I read somewhere that someone was saying that he was not familiar with network path and I don't remember if it was the developper or just a user. Anwyay. It's working now, but I'm still wondering what was the purpose of the lines we have changed (especially since all the rest, I mean running it locally or with variables, seem to work perfectly from here even with those lines changed).

[Kelsenellenelvian]

Will do some testing and thanx maybe you found a solution for everyone.

[athomsen]

Thanks for explaining further Grizzly_MV. I had a similiar explanation written but thought that long of a post might scare readers away

kelsenellenelvian, I will also be testing it in a large network deployment as soon as I can find the time. I will report back any problems I have, if any.

Edited July 26, 2005 by athomsen

[Kelsenellenelvian]

Is there any effect with programing entries for normal use (through the config wizard)?

I am trying to figure out if the changes above will affect the great majority of users that use WPI in non-network situations.

Those lines may have been put it there by one of the last developers but I have no clue what their original purpoose was. As long as everything else works okay the changes will be reflected in the next version.

Edited July 26, 2005 by kelsenellenelvian

[athomsen]

Changing the line in configwizard.js is what makes this work in config wizard. Normal paths (like from CD) do not use \\ so nothing else should be effected that I can think of.

[jcarle]

Often times, when you see a replacement of \\ for \ in a path variable, it's usually because somewhere there's possibility of a path being appended that can do that.

Example:

If the original variable contained:

C:\Program Files\

And you appended \CompanyFolder to it, you'd end up with

C:\Program Files\\CompanyFolder

which is an invalid path, therefore a replace on \\ for \ is a quick and dirty wait to prevent that error from occuring.

[athomsen]

jcarle, I see where you are going with that. However, in this case we are not programatically appending to the paths (unless I missed it - it is still early). So, if users are typing paths in I would think that a WYSIWYG approach would be better then modifing what they typed.

But on the same note, since this change effects all of the fields/functions that use GetConfigValue will this change hinder anyone that may have some really complex conditions?

Anyone with some "really complex conditions" care to comment?

Edited July 26, 2005 by athomsen

[athomsen]

Ok, I am a meat head.

It just hit me that we do programatically change paths - in generate.js for environment variables. I will look into it more in the morning when I have the code in front of me.

[jcarle]

I've done the old \\ to \ switch in appended paths so often that I can't help but to think of it everytime I see a replace for \\.

[athomsen]

Line 122 in generate.js was to correct paths after replacing the environment variables - changing \\\\ into \\.

Because of the changes I made when I use environment variables the registry key created has two extra slashes in it. This is because the are added when replacing environtment variables. The beautiful thing is that windows just ignores the extra slashes.

I think the best solution is to remove all of the slashes added after the environment variables in lines 100 - 108. I do not know how this will effect those who use the FindCDRom function because I have never used WPI from CD. This change would make environment variables function as they do in windows - if you need to get to a folder below the variable you must follow it with a slash.

This change may effect many users but I think it is really more correct because it is the way all other windows programs function <- just my 2 cents.

P.S. Just checked and it seems that the FindCDRom function adss a single extra slash to the path not two as the other lines do.