Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Networking issue

May
3,515
5
This is not a complaint, just looking for suggestions. Yesterday, when the CWD of a TCC session was a mapped network drive, I removed the laptop from the network. The end of my prompt is the CWD, displayed using the special prompt string $P. Naturally, this does not work too well once the directory went missing (inaccessible), resulted in a "network path not found" message (displayed BEFORE the prompt). How can I avoid the error message and error condition? One possibility that failed was to use the POST_EXEC alias to check that %_DISK and %_CWD is still accessible, and IF NOT, bail out to a directory which is nearly certain to still exist (e.g. TCMD's own). I am now stumped!
--
Steve
 
On Tue, 08 Nov 2011 13:45:36 -0500, Steve Fabian <> wrote:

|This is not a complaint, just looking for suggestions. Yesterday, when the CWD of a TCC session was a mapped network drive, I removed the laptop from the network. The end of my prompt is the CWD, displayed using the special prompt string $P. Naturally, this does not work too well once the directory went missing (inaccessible), resulted in a "network path not found" message (displayed BEFORE the prompt). How can I avoid the error message and error condition? One possibility that failed was to use the POST_EXEC alias to check that %_DISK and %_CWD is still accessible, and IF NOT, bail out to a directory which is nearly certain to still exist (e.g. TCMD's own). I am now stumped!

If CWD is a mapped drive and you unmap it. You have an error condotion
(period!). And I suspect TCC is going to tell you about it whenever it tries to
do anything involving the CWD (including issuing a prompt woth $P in it). The
only reasonable solution is not to pull TCC's CWD out from under it.
 
From: vefatica
| If CWD is a mapped drive and you unmap it. You have an error condotion
| (period!). And I suspect TCC is going to tell you about it whenever
| it tries to
| do anything involving the CWD (including issuing a prompt woth $P in
| it). The
| only reasonable solution is not to pull TCC's CWD out from under it.

I did not "unmap" it, the mapping (Z: \\laptop\c) was still valid, but the laptop (of which it was part) itself was disconnected from the network (and powered off). I am sure this happens to many of us. Many times when I did this TCC was minimized to the tray. Is it an error condition on the TCC side? Yes, it is. That's why I am trying to come up with a method that detects the problem and changes the CWD before it is detected through another prompt. BTW, it does not seem to be a problem as long as no TCC action is requested that requires checking what CWD is, i.e., if I remove $P from the prompt, and do not try to access the Z: drive, TCC does not complain. That's why I can change CWD from the command line. But the command fragment "if %@ready[%_disk:] EQ 0" (when _disk is Z) fails with an error report after a long delay. So how can I check that the current default drive (_disk) is still accessible without an error message? BTW, this can happen due to uncontrollable causes, too!
--
Steve
 
Without being too much of a smart-ass, how about "C:<enter>"?

-SAM




From: vefatica
| If CWD is a mapped drive and you unmap it. You have an error condotion
| (period!). And I suspect TCC is going to tell you about it whenever
| it tries to
| do anything involving the CWD (including issuing a prompt woth $P in
| it). The
| only reasonable solution is not to pull TCC's CWD out from under it.

I did not "unmap" it, the mapping (Z: \\laptop\c) was still valid, but the
laptop (of which it was part) itself was disconnected from the network
(and powered off). I am sure this happens to many of us. Many times when I
did this TCC was minimized to the tray. Is it an error condition on the
TCC side? Yes, it is. That's why I am trying to come up with a method that
detects the problem and changes the CWD before it is detected through
another prompt. BTW, it does not seem to be a problem as long as no TCC
action is requested that requires checking what CWD is, i.e., if I remove
$P from the prompt, and do not try to access the Z: drive, TCC does not
complain. That's why I can change CWD from the command line. But the
command fragment "if %@ready[%_disk:] EQ 0" (when _disk is Z) fails with
an error report after a long delay. So how can I check that the current
default drive (_disk) is still accessible without an error message? BTW,
this can happen due to uncontrollable causes, too!
--
Steve
 
On Tue, 08 Nov 2011 17:13:34 -0500, rconn <> wrote:

|---Quote---
|> That's why I am trying to come up with a method that detects
|> the problem and changes the CWD before it is detected
|> through another prompt.
|---End Quote---
|It's not a TCC issue, it's a Windows issue. You're hanging inside a Windows
|API, so you're going to have to seek relief from Microsoft.

I haven't researched it (I will) but I'd guess some sort of notification of a
network disconnection (or unmapping) should be available, perhaps by
subscription.

Even if it were, what should TCC do? Should currently executing commands or
batch files, being likely to depend on the CWD (even existing!) be cancelled.
Should TCC automatically change to some CWD guaranteed to exist (which one?),
give a warning, and re-issue the prompt?
 
From: samintz
| Without being too much of a smart-ass, how about "C:"?

Scott:
The problem is that detecting the problem exists cannot be done without getting an error message. Once that happens, switching to a valid directory is easy.
--
Steve
 
Steve wrote:
| That's why I am trying to come up with a method that detects
| the problem and changes the CWD before it is detected
| through another prompt.

Rex wrote:
| It's not a TCC issue, it's a Windows issue. You're hanging inside a
| Windows API, so you're going to have to seek relief from Microsoft.

Rex:
Assume Z: is a mapped network drive. Does %@ready[z:] hang if the drive is currently not available, e.g., its system is powered down?

Vince wrote:
| I haven't researched it (I will) but I'd guess some sort of
| notification of a
| network disconnection (or unmapping) should be available, perhaps by
| subscription.

I just looked an NETMONITOR, and according to the help text, it monitors whether or not the local machine is connected to a particular network, not whether or not another machine is connected. There is no monitor command to keep track of the accessibility of other machines. That's what I would need to solve the problem.

| Even if it were, what should TCC do? Should currently executing commands or
| batch files, being likely to depend on the CWD (even existing!) be cancelled.
| Should TCC automatically change to some CWD guaranteed to exist (which one?),
| give a warning, and re-issue the prompt?

None of the above. The CWD path had to be was accessible when it became the CWD, so only its continued accessibility would need to be monitored so as to make it possible for the user to TEST current accessibility with no delays and no error message. The test could be done in POST_EXEC, or in the prompt itself, e.g, using @exec or @execstr, and appropriate action taken if needed as the user finds it suitable.
--
Steve
 
> Assume Z: is a mapped network drive. Does %@ready[z:] hang if the drive
> is currently not available, e.g., its system is powered down?

That's entirely up to your file system redirector, not TCC. @READY asks
Windows if the drive is available. It can't do anything if Windows doesn't
know that the drive isn't available (and Windows hangs during the query),
which is the problem in your case. Windows thinks the drive *is* available,
but Windows (eventually) times out when it can't communicate with the drive.
 
|| Assume Z: is a mapped network drive. Does %@ready[z:] hang if the
|| drive is currently not available, e.g., its system is powered down?
|
| That's entirely up to your file system redirector, not TCC. @READY asks
| Windows if the drive is available. It can't do anything if Windows doesn't
| know that the drive isn't available (and Windows hangs during the query),
| which is the problem in your case. Windows thinks the drive *is* available,
| but Windows (eventually) times out when it can't communicate with the drive.

When you state "Windows hangs during the query", does it mean that ALL processes are hanging, or does it delay only the process which made the query? Is there a difference btw. WinXP and Win7 behavior under these circumstances?

Independently of the above, is it possible to monitor network connection health?
--
Steve
 
> When you state "Windows hangs during the query", does it mean that
> ALL processes are hanging, or does it delay only the process which made
> the query?

Only the one process.


> Is there a difference btw. WinXP and Win7 behavior under these
> circumstances?

No.


> Independently of the above, is it possible to monitor network
> connection health?

Not in TCC. It's possible if you want to write your own network redirector
& file system driver.
 
The CWD path had to be was accessible when it became the CWD, so only its continued accessibility would need to be monitored so as to make it possible for the user to TEST current accessibility with no delays and no error message
I've fallen foul of this issue with Windows taking (much) longer than I'd like before timing out over the availability of a network resource and the 'best' way that I've found of working around that it is to use @PING with the machine name, where I can control the timeout. However, in your instance that relies on being able to identify the machine name associated with the current directory - although perhaps that could be identified (via @TRUENAME) at the point that the directory becomes current and recorded somewhere for use in the subsequent check?? I'm afraid that I don't have time to experiment, as I have to go to work, so all I can offer is the possibility.
 

Similar threads

Back
Top