UNC paths vs Mapped drives

Hi, firstly appologies if this has been asked a thousand times before.
I'm all Googled out and haven't really got any answers yet. Maybe
because it a question that doesn;t have any, but well see...

We have an NT based network at work and 'our' share on a particular
server is moving to a new one soon. The time has come to change all the
lovely hard coded paths in all our code. Some are hard coded as drive
letters (always the same one) and some to the UNC path. As far as I
know it's the same drive letter for everyone who uses it, so it's not a
case of using UNC path's because the users can pick and choose where
it's mapped to.

Do you know which is faster - accessing information on a network via a
drive letter or a UNC path - or is there no difference?
Thinking about it I wonder if using the UNC would be faster - wouldn't
the UNC path behind the mapped drive letter have to be resolved every
time it's used, causing a (albeit) small time lag???

Seeing as the changes we make will probably stick for quite some time,
despite knowing that we really should get rid of the hard coded path's,
I guess it would be best to change them to the fastest one.

Many thanks for any help or pointers in the right direction
Chris

Always use UNC paths. Mapped drives are a things of the past going back to
the DOS Client and Netware days. It is like rubbing two sticks together to
start a connection,...turning a crank on the computer to boot it up.

It isn't really a speed issue, it is a dependability and scalebility issue.
You also are not limited to the 26 letters in the alphabet.. UNC paths don't
"timeout" and disconnect the way mapped drives do either because they aren't
trying to maintain a constant state, they are only active during the moment
they are being used (depending on the design of the application using them).

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com


"Chris" <(E-Mail Removed)> wrote in message
news:200411231459485627%chriswheatley@maccom...
> Do you know which is faster - accessing information on a network via a
> drive letter or a UNC path - or is there no difference?
> Thinking about it I wonder if using the UNC would be faster - wouldn't
> the UNC path behind the mapped drive letter have to be resolved every
> time it's used, causing a (albeit) small time lag???

On 2004-11-23 15:49:35 +0000, "Phillip Windell" <@.> said:

> Always use UNC paths. Mapped drives are a things of the past going back to
> the DOS Client and Netware days. It is like rubbing two sticks together to
> start a connection,...turning a crank on the computer to boot it up.
>
> It isn't really a speed issue, it is a dependability and scalebility issue.
> You also are not limited to the 26 letters in the alphabet.. UNC paths don't
> "timeout" and disconnect the way mapped drives do either because they aren't
> trying to maintain a constant state, they are only active during the moment
> they are being used (depending on the design of the application using them).

Thanks,

Unfortunately telling these users that using mapped drives are a thing
of the past won't cut it. This is the civil service and things of the
past are always filed in the 'Good' folder, if you get my drift. I
know that you should always use UNC paths, but I'm looking for a hook
to sell to the users. I had a gut feeling about the speed thing, and
that's what they're complaining about the most at the moment.

The options available to us are:

a) rip through all the code and change the old UNC paths to the new UNC
paths, and do nothing else. Easiest from our point of view and perhaps
from a implementation point of view also, even though it's the least
amount of changes, we're still talking about a few thousand changes
here.

b) change all references to the old UNC path to 'the drive letter'. I
don't want to do this.

c) change all references of the old UNC path to the new one and all
references to 'the drive letter' to the new UNC path too. This is what
I'd like to do, but I have to sell it to them.

Any options from this point on won't get done as this is legacy code
which is mearly being maintained whilst whole new systems are being
written to replace it.

c) get rid of all hard cocded references.

d) rewrite everything

If I have to sell the dependability side then I will, but I was looking
for something a little more "user beneficial"

"Chris" <(E-Mail Removed)> wrote in message
news:2004112316143865203%chriswheatley@maccom...
> On 2004-11-23 15:49:35 +0000, "Phillip Windell" <@.> said:

> c) change all references of the old UNC path to the new one and all
> references to 'the drive letter' to the new UNC path too. This is what
> I'd like to do, but I have to sell it to them.
>
> Any options from this point on won't get done as this is legacy code
> which is mearly being maintained whilst whole new systems are being
> written to replace it.
>
> c) get rid of all hard cocded references.

You had two "c"s,...but they go together anyway. An application should
never have stuff like this "hardcoded". These things should always be a
Configuration Option that you can change within some sort of Management
Interface. In my opinion the Management Interface (screen?), and the
configurable options and methods that go with it, should be the first things
the programmers work on before they get to the user's screens. An
application that cannot be properly reconfigured after "in use" without
rewriting source code is a disaster waiting to happen.

I don't know what to tell you about selling something to users. I never sell
to the users,...I sell my ideas to the management in charge, then I tell (or
management tells) the user the way it is going to be. Since they pay me to
do what I do, they consider most of ideas fairly and usually agree.

Now if, as you say, new systems are being written to replace the old,...then
why bother?..just band-ade it together until it is replaced. There's no
point in waisting a bunch of time with it if it is going to go away anyhow.
Then hope and pray that whoever writes the new ones know what they are doing
a little better.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

On 2004-11-23 18:28:14 +0000, "Phillip Windell" <@.> said:

> "Chris" <(E-Mail Removed)> wrote in message
> news:2004112316143865203%chriswheatley@maccom...
>> On 2004-11-23 15:49:35 +0000, "Phillip Windell" <@.> said:
>
>> c) change all references of the old UNC path to the new one and all
>> references to 'the drive letter' to the new UNC path too. This is what
>> I'd like to do, but I have to sell it to them.
>>
>> Any options from this point on won't get done as this is legacy code

Philip, thanks for the "hey, your crap and I'm not" lecture. Doesnt
really answer my question though.

If anyone else can answer the questions then it would be much appreciated.

Many thanks
Chris

"Chris" <(E-Mail Removed)> wrote in message
news:2004112319514326044%chriswheatley@maccom...
> On 2004-11-23 18:28:14 +0000, "Phillip Windell" <@.> said:
>
> > "Chris" <(E-Mail Removed)> wrote in message
> > news:2004112316143865203%chriswheatley@maccom...
> >> On 2004-11-23 15:49:35 +0000, "Phillip Windell" <@.> said:
> >
> >> c) change all references of the old UNC path to the new one and all
> >> references to 'the drive letter' to the new UNC path too. This is what
> >> I'd like to do, but I have to sell it to them.
> >>
> >> Any options from this point on won't get done as this is legacy code
>
> Philip, thanks for the "hey, your crap and I'm not" lecture. Doesnt
> really answer my question though.

Huh? Where'd that come from? All I'm saying is that I think you are stuck.
With any of your options that are proper solutions you say you either don't
want to do it, or the users won't let you do it. Then you said replacements
for the whole thing are in the making, ...so what am I supposed to say??

Obviously correcting the code so that it uses UNC consistantly across the
board would be an improvement, even if it is hardcoded. But you say the
users won't let you. Now if the users have the authority, and get to tell
you how to do things, then just give them what they want,... good, bad, or
whatever,......what else you supposed to do?

It would be better to design a configuration interface into the application
so that it allows change to be done easily,...but if a replacement is in the
making then how much time do you want to devote to a "dead" product?

I don't know what else you want.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

I was thinking,...why are the users even aware of the UNC vs Mapped Drive
issue to begin with if it is hardcoded into the App? If they enter the path
or drive letter then in what way is it hardcoded?....but if it is hardcoded
then why would they have to type in a UNC or drive letter or even know about
it in the first place? Having a better understanding of what is happening
there would make a big difference, although this is a networking group and
not a programming group.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

On 2004-11-23 20:32:38 +0000, "Phillip Windell" <@.> said:

> I was thinking,...why are the users even aware of the UNC vs Mapped Drive
> issue to begin with if it is hardcoded into the App? If they enter the path
> or drive letter then in what way is it hardcoded?....but if it is hardcoded
> then why would they have to type in a UNC or drive letter or even know about
> it in the first place? Having a better understanding of what is happening
> there would make a big difference, although this is a networking group and
> not a programming group.

Couldn't agree more. This is a networking group, which was why I was
asking about network performance issues, and not a programming group
which was why I was surprised about the 'how to program' lecture.

Life in the public sector is a little different from life in the
private sector. The users are semi technical, with some knowledge from
years gone by - "we had to do it all ourselves once don't you know".
They can be quite forceful and the management of this task is of the -
it's up to you to sort it out between yourselves variety.

We are a team brought in to support legacy apps whilst the 'staff' go
off and write the new ones. We don't have the time or resources to do a
re-write or even to put in configuration management - at the moment. I
want to present a solution that is technically correct. They would
appreciate that instead of us outsiders insisting our new fangled ways
upon them.

If I'm wrong and hard coded drive letters is the lesser of 2 evils then
fair enough. I just had a gut feeling about UNC path's having a
technical merit over them and wanted to sound it out.

However, I thank you for your advice and time
Chris

"Chris" <(E-Mail Removed)> wrote in message
news:2004112321171480369%chriswheatley@maccom...
> On 2004-11-23 20:32:38 +0000, "Phillip Windell" <@.> said:
> Couldn't agree more. This is a networking group, which was why I was
> asking about network performance issues, and not a programming group
> which was why I was surprised about the 'how to program' lecture.

Sorry, just trying to go to the heart of the matter. Many networking woes
are caused by the evils of some programmer (who usually isn't there
anymore).

> We are a team brought in to support legacy apps whilst the 'staff' go
> off and write the new ones. We don't have the time or resources to do a
> re-write or even to put in configuration management - at the moment. I
> want to present a solution that is technically correct. They would
> appreciate that instead of us outsiders insisting our new fangled ways
> upon them.

I see,...they say,.."Fix it,... fix it quickly,...but don't change
anything!"

> If I'm wrong and hard coded drive letters is the lesser of 2 evils then
> fair enough. I just had a gut feeling about UNC path's having a
> technical merit over them and wanted to sound it out.

Which takes longer?,..changing the hardcoded drive letters or the UNC paths?
I think using UNC paths consistantly across the board would be better than
drive letters, especially if it took that same amount, or near same amount
of time. Mapped Drives also do have the timeout issue which seems worse with
XP clients, and you would dodge that with UNC paths. But if they won't let
you then I guess you are stuck doing it their way.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

On 2004-11-23 21:34:41 +0000, "Phillip Windell" <@.> said:
>
> Sorry, just trying to go to the heart of the matter. Many networking woes
> are caused by the evils of some programmer (who usually isn't there
> anymore).

Programmer's - evil - surely not...