[Bug?] [VW7.2] More UNC wierdness

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug?] [VW7.2] More UNC wierdness

Stew MacLean

Hi,

 

I’ve been using UNC filenames to test a client server setup of XP as the “client”, and an old NT4 box as the “server”.

 

Running the following from the XP box I get:

 

“A valid machine address…”

 

'\\10.1.1.3\C$\Program Files' asFilename                                                 a NTFSFilename('\\10.1.1.3\c$\Program Files')

Time millisecondsToRun: ['\\10.1.1.3\C$\Program Files' asFilename]          3

 

 

“An invalid machine address…”

 

'\\10.1.1.4\C$\Program Files' asFilename                                                 a FATFilename('\\10.1.1.4\c$\programf')

Time millisecondsToRun: ['\\10.1.1.4\C$\Program Files' asFilename]          41997

 

Please note when the machine is invalid the answering of a truncated FAT file name, but more significantly the amount of time it took to answer it.

 

Is this a windows thing or a problem with the primitive?

 

Cheers,

 

Stewart

Reply | Threaded
Open this post in threaded view
|

RE: [Bug?] [VW7.2] More UNC wierdness

Bob Jarvis-3
Perhaps it's a network thing.  Try pinging the two machines and see how long it takes for each to answer (or not, as the case may be).
 
Bob


From: Stewart MacLean [mailto:[hidden email]]
Sent: Thursday, February 23, 2006 1:48 PM
To: [hidden email]
Subject: [Bug?] [VW7.2] More UNC wierdness

Hi,

 

I’ve been using UNC filenames to test a client server setup of XP as the “client”, and an old NT4 box as the “server”.

 

Running the following from the XP box I get:

 

“A valid machine address…”

 

'\\10.1.1.3\C$\Program Files' asFilename                                                 a NTFSFilename('\\10.1.1.3\c$\Program Files')

Time millisecondsToRun: ['\\10.1.1.3\C$\Program Files' asFilename]          3

 

 

“An invalid machine address…”

 

'\\10.1.1.4\C$\Program Files' asFilename                                                 a FATFilename('\\10.1.1.4\c$\programf')

Time millisecondsToRun: ['\\10.1.1.4\C$\Program Files' asFilename]          41997

 

Please note when the machine is invalid the answering of a truncated FAT file name, but more significantly the amount of time it took to answer it.

 

Is this a windows thing or a problem with the primitive?

 

Cheers,

 

Stewart




This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please
do not forward, copy, print, use or disclose this communication to
others; also please notify the sender by replying to this message,
and then delete it from your system. The Timken Company / The
Timken Corporation

Reply | Threaded
Open this post in threaded view
|

RE: [Bug?] [VW7.2] More UNC wierdness

Stew MacLean

Good idea Bob,

 

The existing machine answers in less than a millisecond.

The non existing machine gets it’s first time out within 5 seconds.

 

So it’s not the network.

 

Cheers,

 

Stewart

 

-----Original Message-----
From: Jarvis, Robert P. (Bob) (Contingent) [mailto:[hidden email]]
Sent:
24 February 2006 8:05
To: [hidden email]
Subject: RE: [Bug?] [VW7.2] More UNC wierdness

 

Perhaps it's a network thing.  Try pinging the two machines and see how long it takes for each to answer (or not, as the case may be).

 

Bob

 


From: Stewart MacLean [mailto:[hidden email]]
Sent:
Thursday, February 23, 2006 1:48 PM
To: [hidden email]
Subject: [Bug?] [VW7.2] More UNC wierdness

Hi,

 

I’ve been using UNC filenames to test a client server setup of XP as the “client”, and an old NT4 box as the “server”.

 

Running the following from the XP box I get:

 

“A valid machine address…”

 

'\\10.1.1.3\C$\Program Files' asFilename                                                a NTFSFilename('\\10.1.1.3\c$\Program Files')

Time millisecondsToRun: ['\\10.1.1.3\C$\Program Files' asFilename]        3

 

 

“An invalid machine address…”

 

'\\10.1.1.4\C$\Program Files' asFilename                                                a FATFilename('\\10.1.1.4\c$\programf')

Time millisecondsToRun: ['\\10.1.1.4\C$\Program Files' asFilename]        41997

 

Please note when the machine is invalid the answering of a truncated FAT file name, but more significantly the amount of time it took to answer it.

 

Is this a windows thing or a problem with the primitive?

 

Cheers,

 

Stewart




This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please
do not forward, copy, print, use or disclose this communication to
others; also please notify the sender by replying to this message,
and then delete it from your system. The Timken Company / The
Timken Corporation

Reply | Threaded
Open this post in threaded view
|

RE: [Bug?] [VW7.2] More UNC wierdness

Steven Kelly
In reply to this post by Stew MacLean
Message
It's probably a Windows thing: try Start | Run | \\10.1.1.4\C$\Program Files. I'm used to waiting up to a minute for something like that, if the machine doesn't exist (just tried, and it took 4½ minutes to reply - makes VW's 40 seconds on my machine look speedy!). It also depends on your DNS settings and server, WINS settings and server, and Windows node types. The VW #asFilename code is rather baroque and inefficient, but at worst a few milliseconds.
 
Of course, it's debatable if VW should be trying to do anything with the network at that point, or just returning a Filename with the appropriate string inside it. VW takes the generally sensible approach of trying to find out what the root drive is for that string, and query it with #getFileSystemAttributes: to get its file system type (FAT, NTFS, Unix etc.). That's what invokes the long Windows delay, composed of nameserver lookups and timeouts.
 
Steve
-----Original Message-----
From: Stewart MacLean [mailto:[hidden email]]
Sent: 23 February 2006 20:48
To: [hidden email]
Subject: [Bug?] [VW7.2] More UNC wierdness

Hi,

 

I’ve been using UNC filenames to test a client server setup of XP as the “client”, and an old NT4 box as the “server”.

 

Running the following from the XP box I get:

 

“A valid machine address…”

 

'\\10.1.1.3\C$\Program Files' asFilename                                                 a NTFSFilename('\\10.1.1.3\c$\Program Files')

Time millisecondsToRun: ['\\10.1.1.3\C$\Program Files' asFilename]          3

 

 

“An invalid machine address…”

 

'\\10.1.1.4\C$\Program Files' asFilename                                                 a FATFilename('\\10.1.1.4\c$\programf')

Time millisecondsToRun: ['\\10.1.1.4\C$\Program Files' asFilename]          41997

 

Please note when the machine is invalid the answering of a truncated FAT file name, but more significantly the amount of time it took to answer it.

 

Is this a windows thing or a problem with the primitive?

 

Cheers,

 

Stewart

Reply | Threaded
Open this post in threaded view
|

RE: [Bug?] [VW7.2] More UNC wierdness

Stew MacLean
Message

Indeed, it’s in the order of a minute – which doesn’t make VW look quite so bad.

 

Lets hope the user keys in the right path!

 

Thanks guys,

 

Cheers,

 

Stewart

 

-----Original Message-----
From: Steven Kelly [mailto:[hidden email]]
Sent:
24 February 2006 8:42
To: Stewart MacLean; [hidden email]
Subject: RE: [Bug?] [VW7.2] More UNC wierdness

 

It's probably a Windows thing: try Start | Run | \\10.1.1.4\C$\Program Files. I'm used to waiting up to a minute for something like that, if the machine doesn't exist (just tried, and it took 4½ minutes to reply - makes VW's 40 seconds on my machine look speedy!). It also depends on your DNS settings and server, WINS settings and server, and Windows node types. The VW #asFilename code is rather baroque and inefficient, but at worst a few milliseconds.

 

Of course, it's debatable if VW should be trying to do anything with the network at that point, or just returning a Filename with the appropriate string inside it. VW takes the generally sensible approach of trying to find out what the root drive is for that string, and query it with #getFileSystemAttributes: to get its file system type (FAT, NTFS, Unix etc.). That's what invokes the long Windows delay, composed of nameserver lookups and timeouts.

 

Steve

-----Original Message-----
From: Stewart MacLean [mailto:[hidden email]]
Sent:
23 February 2006 20:48
To: [hidden email]
Subject: [Bug?] [VW7.2] More UNC wierdness

Hi,

 

I’ve been using UNC filenames to test a client server setup of XP as the “client”, and an old NT4 box as the “server”.

 

Running the following from the XP box I get:

 

“A valid machine address…”

 

'\\10.1.1.3\C$\Program Files' asFilename                                             a NTFSFilename('\\10.1.1.3\c$\Program Files')

Time millisecondsToRun: ['\\10.1.1.3\C$\Program Files' asFilename]     3

 

 

“An invalid machine address…”

 

'\\10.1.1.4\C$\Program Files' asFilename                                             a FATFilename('\\10.1.1.4\c$\programf')

Time millisecondsToRun: ['\\10.1.1.4\C$\Program Files' asFilename]     41997

 

Please note when the machine is invalid the answering of a truncated FAT file name, but more significantly the amount of time it took to answer it.

 

Is this a windows thing or a problem with the primitive?

 

Cheers,

 

Stewart

Reply | Threaded
Open this post in threaded view
|

RE: [Bug?] [VW7.2] More UNC wierdness

Bob Jarvis-3
In reply to this post by Stew MacLean
Message
I just tried Steve's experiment.  Took about 15 seconds to tell me the network path didn't exist.
 
Bob


From: Steven Kelly [mailto:[hidden email]]
Sent: Thursday, February 23, 2006 2:42 PM
To: Stewart MacLean; [hidden email]
Subject: RE: [Bug?] [VW7.2] More UNC wierdness

It's probably a Windows thing: try Start | Run | \\10.1.1.4\C$\Program Files. I'm used to waiting up to a minute for something like that, if the machine doesn't exist (just tried, and it took 4½ minutes to reply - makes VW's 40 seconds on my machine look speedy!). It also depends on your DNS settings and server, WINS settings and server, and Windows node types. The VW #asFilename code is rather baroque and inefficient, but at worst a few milliseconds.
 
Of course, it's debatable if VW should be trying to do anything with the network at that point, or just returning a Filename with the appropriate string inside it. VW takes the generally sensible approach of trying to find out what the root drive is for that string, and query it with #getFileSystemAttributes: to get its file system type (FAT, NTFS, Unix etc.). That's what invokes the long Windows delay, composed of nameserver lookups and timeouts.
 
Steve
-----Original Message-----
From: Stewart MacLean [mailto:[hidden email]]
Sent: 23 February 2006 20:48
To: [hidden email]
Subject: [Bug?] [VW7.2] More UNC wierdness

Hi,

 

I’ve been using UNC filenames to test a client server setup of XP as the “client”, and an old NT4 box as the “server”.

 

Running the following from the XP box I get:

 

“A valid machine address…”

 

'\\10.1.1.3\C$\Program Files' asFilename                                                 a NTFSFilename('\\10.1.1.3\c$\Program Files')

Time millisecondsToRun: ['\\10.1.1.3\C$\Program Files' asFilename]          3

 

 

“An invalid machine address…”

 

'\\10.1.1.4\C$\Program Files' asFilename                                                 a FATFilename('\\10.1.1.4\c$\programf')

Time millisecondsToRun: ['\\10.1.1.4\C$\Program Files' asFilename]          41997

 

Please note when the machine is invalid the answering of a truncated FAT file name, but more significantly the amount of time it took to answer it.

 

Is this a windows thing or a problem with the primitive?

 

Cheers,

 

Stewart




This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please
do not forward, copy, print, use or disclose this communication to
others; also please notify the sender by replying to this message,
and then delete it from your system. The Timken Company / The
Timken Corporation