greg ercolano

I noticed that 'net use' doesn't show *all* the drive maps,
it only shows maps created by the current user.

In a multiuser context, this is bad, because one can't 'see' what
drive maps are currently in use by other accounts.

For instance, under Win2K say 'fred' is logged into a workstation,
and he creates a drive map for Z:

Then 'jack' telnet's into the same workstation's Win2K Telnet Server,
and creates a drive map for 'X:'.

If jack types 'net use', he only sees his X: map.
If fred types 'net use', he only sees his Z: map.

Both users can access both drive maps (eg. with 'dir X:'),
but the 'net use' command isn't showing the maps owned by
the other user.

There must surely be a way to see *all* the maps.
Is there a command to show this?

scherbina vladimir

Most likely GetLogicalDriveStrings + GetDriveType will help you.

--
Vladimir

arkady frenkel

Look at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q180362
for details ( each user has it's own set )
Arkady

greg ercolano

Thanks.

Yes, those two WIN32 calls do seem to show the mapped drive letters
for both the telnet'ed user, and the currently logged in user.

Not really DOS commands, but I'll take what I can get

Wrote a small C++ program to exercise these calls: --- snip
#include <stdio.h>
#include <windows.h>
#include <memory.h>
// Show all drive maps
// Compiles as: cl /TP thisprogram.cxx
int main() {
char s[4096];
char *ss = s;
memset(s,0,sizeof(s));
if ( GetLogicalDriveStrings(sizeof(s)-1, s) == 0 ) {
fprintf(stderr, "GetLogicalDriveStrings() failed: %d\n", GetLastError());
return(1);
}
while ( *ss ) {
char uncpath[4096];
memset(uncpath, 0, sizeof(uncpath));
char drivename[10];
sprintf(drivename, "%.2s", ss);
if ( QueryDosDevice(drivename, uncpath, sizeof(uncpath)-1) == 0 ) {
fprintf(stderr, "QueryDosDevice(%s) failed: %d\n", drivename, GetLastError());
continue;
}
fprintf(stderr, "%s -- %s\n", drivename, uncpath);
ss += strlen(s) + 1;
}
return(0);
}
--- snip

Not perfect code, but good enough for testing.

When I run it, it shows both the X: and Z: drive maps, each created
by a different user:

C: -- \Device\HarddiskVolume1
D: -- \Device\CdRom0
E: -- \Device\Harddisk1\DP(1)0-0+6
F: -- \Device\Harddisk2\DP(1)0-0+7
G: -- \Device\Harddisk3\DP(1)0-0+8
H: -- \Device\Harddisk4\DP(1)0-0+9
X: -- \Device\LanmanRedirector\;X:0\meade\vartmp
Z: -- \Device\LanmanRedirector\;Z:0\meade\net

..in my case, X: is mapped to \\meade\vartmp, and Z: is mapped to \\meade\net.

I imagine sysadmins without compiler skills might have a problem with this,
though. Fortunately "ActiveState Perl" seems to also have access to these
WIN32 functions, so I guess it's not completely inaccessible.

greg ercolano

Thanks, good info.

The relevant text regarding 'net use' not showing all the info
is probably this bit:

--- snip
If a user tries to enumerate the list of redirected drives through WNetOpenEnum()
and WNetEnumResource(), the functions only list redirected drives that were established
by that user. Drives that were redirected by other users will not be visible.
--- snip

What scares me is Microsoft saying this:
--- snip
A service should not directly access local or network resources through mapped drive letters.
--- snip

Taken at face value, that means folks who telnet in to a DOS prompt
can't use drive letters. (telnet is a service)

But sometimes you are forced to use drive letters, because some DOS
commands don't support UNC paths, such as 'cd' and 'chdir':
C:\>cd \\meade\net\tmp
'\\meade\net\tmp' is an invalid current directory path. UNC paths are not supported.

..which means you're SOL if you want to run 'nmake' or 'cl'
in a network directory.

Fortunately drive maps /do/ seem to work from telnet.

Good thing too, because AFAIK, there's no way around the DOS
CHDIR problem with UNC paths, which is I think is more of a legacy issue
with DOS than it is a technical issue with WIN32, which I think fully
supports UNCs, even for chdir().

arkady frenkel

Hi!
In advance...

Being service telnet can receive that data from user part of it, where no
problems with mentioned function Arkady

scherbina vladimir

Most likely GetLogicalDriveStrings + GetDriveType will help you.

--
Vladimir

arkady frenkel

Look at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q180362
for details ( each user has it's own set )
Arkady

greg ercolano

Thanks.

Yes, those two WIN32 calls do seem to show the mapped drive letters
for both the telnet'ed user, and the currently logged in user.

Not really DOS commands, but I'll take what I can get

Wrote a small C++ program to exercise these calls: --- snip
#include <stdio.h>
#include <windows.h>
#include <memory.h>
// Show all drive maps
// Compiles as: cl /TP thisprogram.cxx
int main() {
char s[4096];
char *ss = s;
memset(s,0,sizeof(s));
if ( GetLogicalDriveStrings(sizeof(s)-1, s) == 0 ) {
fprintf(stderr, "GetLogicalDriveStrings() failed: %d\n", GetLastError());
return(1);
}
while ( *ss ) {
char uncpath[4096];
memset(uncpath, 0, sizeof(uncpath));
char drivename[10];
sprintf(drivename, "%.2s", ss);
if ( QueryDosDevice(drivename, uncpath, sizeof(uncpath)-1) == 0 ) {
fprintf(stderr, "QueryDosDevice(%s) failed: %d\n", drivename, GetLastError());
continue;
}
fprintf(stderr, "%s -- %s\n", drivename, uncpath);
ss += strlen(s) + 1;
}
return(0);
}
--- snip

Not perfect code, but good enough for testing.

When I run it, it shows both the X: and Z: drive maps, each created
by a different user:

C: -- \Device\HarddiskVolume1
D: -- \Device\CdRom0
E: -- \Device\Harddisk1\DP(1)0-0+6
F: -- \Device\Harddisk2\DP(1)0-0+7
G: -- \Device\Harddisk3\DP(1)0-0+8
H: -- \Device\Harddisk4\DP(1)0-0+9
X: -- \Device\LanmanRedirector\;X:0\meade\vartmp
Z: -- \Device\LanmanRedirector\;Z:0\meade\net

..in my case, X: is mapped to \\meade\vartmp, and Z: is mapped to \\meade\net.

I imagine sysadmins without compiler skills might have a problem with this,
though. Fortunately "ActiveState Perl" seems to also have access to these
WIN32 functions, so I guess it's not completely inaccessible.

greg ercolano

Thanks, good info.

The relevant text regarding 'net use' not showing all the info
is probably this bit:

--- snip
If a user tries to enumerate the list of redirected drives through WNetOpenEnum()
and WNetEnumResource(), the functions only list redirected drives that were established
by that user. Drives that were redirected by other users will not be visible.
--- snip

What scares me is Microsoft saying this:
--- snip
A service should not directly access local or network resources through mapped drive letters.
--- snip

Taken at face value, that means folks who telnet in to a DOS prompt
can't use drive letters. (telnet is a service)

But sometimes you are forced to use drive letters, because some DOS
commands don't support UNC paths, such as 'cd' and 'chdir':
C:\>cd \\meade\net\tmp
'\\meade\net\tmp' is an invalid current directory path. UNC paths are not supported.

..which means you're SOL if you want to run 'nmake' or 'cl'
in a network directory.

Fortunately drive maps /do/ seem to work from telnet.

Good thing too, because AFAIK, there's no way around the DOS
CHDIR problem with UNC paths, which is I think is more of a legacy issue
with DOS than it is a technical issue with WIN32, which I think fully
supports UNCs, even for chdir().