DosTips.com

Apologies if this doesn't strictly fit this forum. I'll take no offense if you incinerate it, but tell me where to go if you do. It does involve strictly DOS operation and .BAT in particular.

Right up front, I am ignorant about IP addressing, and what PING and NET USE truly do. I have a basic functional understanding, and know many fragmented details about it, so I won't be as bad as explaining this to your grandmother, but just be warned that I am essentially a connectivity novice.

Scenario: I have two desktops each connected to a cable modem/router. On an XP box I go
net use \\192.168.0.2\users /user:bob
SUBST Q: "\\192.168.0.2\users\bob"

and now I can use Q: from the other (Win 7) box. I commonly run a batch file, and when the other box is turned on and "advanced sharing" c:\users\ there, I want to have the XP batch file go
Q:
cd \foo

However, when the 2nd box is off or asleep or whatever, that Q: can sit there for an eternity before giving up. My solution was to go
ping 192.168.0.2 -n 1 -w 200
and I test the text it returns (because I got misleading, seemingly absurd values from ERRORLEVEL). So I go

for /f %%i in ('ping 192.168.0.2 -n 1 -w 200 ^| findstr /C:"Received = 1"') do (
set state=up
)
if %state% == down (etc.)

Don't worry about the complex "FOR" command. All it's doing is setting an environment variable if "Received = 1" is returned by the ping.

Here's where it gets deeply frustrating. Sometimes I CAN ping it, but I know that the device on the other end is not sharing. That is, dir Q: says "the network name cannot be found" - yet the PING SUCCEEDS.

Today, something new: the ping is failing 100% of the time, even though I can go
DIR Q:
and see everything on the other end of the connection.

BTW I don't know what it means, but you might be interested to hear that ARP -a shows
Interface: 192.168.0.3 --- 0x2
Internet Address Physical Address Type
192.168.0.1 xx-xx-xx-xx-xx-xx dynamic
192.168.0.2 yy-yy-yy-yy-yy-yy dynamic

The goal here is to, in a .BAT, to test if Q is accessible, before issuing
Q:
cd \foo
because it can sit there for a head-splitting eternity if Q: is not currently accessible.

FWIW, I spent hours googling and testing false leads. I found surprisingly few answers on how to test if a drive is currently shared, and the little advice I found is often bad. PING seemed to be my best hope, but I'm open to something else.

Hi,

I have a similar situation between two machines here, a desktop and a laptop.
The desktop stays; The laptop comes and goes.
The desktop accesses a share on the laptop drive as drive U:.
One difference with your scenario is that I don't use subst.exe for generating a drive letter, but net.exe itself: Running just "net use" displays the list of network drives that you're connected to.
When the laptop goes away, the "net use" command on the desktop correctly reports that the U: drive is disconnected.
Now the strange thing is that when the laptop comes back, the desktop does not detect it, and the U drive remains indefinitely disconnected.
If I try accessing it, this hangs forever, like in your case.
I suspect that some layer in Windows silently discards packets intended for disconnected drives, thus preventing an automatic reconnection.

I've found that the only way to reconnect the drive is to repeat the "net use U: \\laptop\share" command. Surprisingly, you don't need to enter the user and password again.
Eventually I've written a script called Reconnect.bat to automate that. I just run and reconnect.bat gets the corresponding server and share information from the registry (recorded by the /persistent option), and issues the right net use command.

Side note: That same script is also useful when you open a command prompt in Administrator mode.
By default, the administrator does not see the user's network drives. Running reconnect.bat fixes that, without having to retype all the complex net use commands.

Thanks for that report. My real problem is that I routinely run .BATs on the always-on machine even when the other side is gone, so re-establishing NET USE isn't practical.

One other difference for me is that the delay is only forever-ish, maybe a minute or something. GENERALLY I experience that pain when the come-and-go P.C. is off, or in Sleep mode or the cable's disconnected. GENERALLY I get an instant failure if it's on and cabled, but merely not "advanced sharing" when I "ask" for access with DIR Q: or Q:

I'm still perplexed by the PING results. I confess that I may have a complete misunderstanding as to whether:

Ping success or failure
is tantamount to?
NET USE reporting 'OK' vs. 'Disconnected' (or its generated ERRORLEVEL)
is tantamount to?
the resource at the other end of the cable allowing sharing
is tantamount to?
Q: or U: actually producing anything, vs. not, and in some cases, quickly failing, and others, sitting there forever-ish.

I confirmed your 'OK vs. Disco' experience in a test just now:
- Share a directory (and its subs) on the [Win 7] come-and-go box.
- Went NET USE on the always on [XP] box. Reports OK.
- Turned off share on the [Win 7] come-and-go box. Wait 15 seconds.
- NET USE on the always on [XP] box still reports OK! (hmm)
- Went DIR Q: (or for you, U:) which immediately gave "The Network name cannot be found."
- NET USE on the always on [XP] box now reports Disconnected (EDIT: sorry, I accidentally left this line out when I first posted this)
- Turned ON share on the [Win 7] come-and-go box
- NET USE on the always on [XP] box still reports Disconnected! (hmm, like you saw)
- Went DIR Q: (or for you, U:) which succeeded.
- NET USE says OK now.

So in my experience, you have to actually "use the connection" first to get NET USE to correctly report status. Of course, that's bad for me, because "using the connection" (going Q: or DIR Q:) is the painful forever-ish operation. Sort of a chicken/egg dilemma for me.

Rerunning the tests above gives same results.

I fear that I have a fundamental misunderstanding of the 4 "tantamount?" conditions above.