Working 'subst' equivalent for WinXP?

[jimrandomh]

An old post said
"The reason this now fails is that on Windows XP, virtual drives (sym
links) are now only visible to the user who created it. On Windows
2000, these were visible to users who didn't create them. For security
reasons, this was closed. As a side effect, it prevents installs on XP
using subst drives."

I'm presently using Win2k and trying to migrate to XP, but this is a
showstopping problem for me. I have a subst'ed drive letter which needs
to be accessible to all users (particularly 'system'). The only
alternative I've found suggested is to use a mapped network drive
instead... but then unplugging my network cable becomes equivalent to
unplugging a hard drive, which is unacceptable.

Security shouldn't be an issue; the command runs as Administrator. I'd
be willing to use a service or device driver in place of subst, so long
as it can achieve the same result. How can I map a drive letter to a
directory under Windows XP? Being able to do this is essential for some
custom-written software/scripts.

 

[Pavel A.]

Map the drives in the same script. Add the subst commands there.
You can store the mapping info for example, in global environment variables.
Any problem with it?

--PA

 

[jimrandomh]

Map the drives in the same script. Add the subst commands there.
You can store the mapping info for example, in global environment
variables. Any problem with it?

Unfortunately, yes there is a problem. I store and install pretty much
everything on the subst'ed drive, so pretty much everything is
affected. The number of programs which would have to set up the subst
mount themselves would be unmanageable, especially since many of them
are compiled programs and service to which I have no source code.

 

[Shenan Stanley]

An old post said
"The reason this now fails is that on Windows XP, virtual drives (sym
links) are now only visible to the user who created it. On Windows
2000, these were visible to users who didn't create them. For
security reasons, this was closed. As a side effect, it prevents
installs on XP using subst drives."

I'm presently using Win2k and trying to migrate to XP, but this is a
showstopping problem for me. I have a subst'ed drive letter which
needs to be accessible to all users (particularly 'system'). The only
alternative I've found suggested is to use a mapped network drive
instead... but then unplugging my network cable becomes equivalent to
unplugging a hard drive, which is unacceptable.

Security shouldn't be an issue; the command runs as Administrator. I'd
be willing to use a service or device driver in place of subst, so
long as it can achieve the same result. How can I map a drive letter
to a directory under Windows XP? Being able to do this is essential
for some custom-written software/scripts.

Map the drives in the same script. Add the subst commands there.
You can store the mapping info for example, in global environment
variables. Any problem with it?

Unfortunately, yes there is a problem. I store and install pretty much
everything on the subst'ed drive, so pretty much everything is
affected. The number of programs which would have to set up the subst
mount themselves would be unmanageable, especially since many of them
are compiled programs and service to which I have no source code.

I still do not see the problem.. if everyone who uses the subst first runs a
script (globally - like a startup script for ALL users or a "wrapper" for
the applications that need this subst drive mapping..) then it's just like
it was before. Everyone on the system has the drive when they need it
because there are scripts in place to insure this.. Anyone who does not need
it - won't have it.

You write a script for each application if you have to - that's one per
script. I have unattended installs with a 100+ scripts.. I have had ghost
distributions with even more.. And a logon/startup script in the ALL USERS
area certainly cannot be beyond any sytstem administrator I know..

 

[jimrandomh]

I still do not see the problem.. if everyone who uses the subst
first runs a script (globally - like a startup script for ALL
users or a "wrapper" for the applications that need this subst
drive mapping..) then it's just like it was before. Everyone on
the system has the drive when they need it because there are
scripts in place to insure this.. Anyone who does not need it -
won't have it.

You write a script for each application if you have to - that's
one per script. I have unattended installs with a 100+ scripts..
I have had ghost distributions with even more.. And a
logon/startup script in the ALL USERS area certainly cannot be
beyond any sytstem administrator I know..

Two problems with using a logon script. First, other items in the
startup folder and in hkey_local_machine/.../run need the drive mapped,
and there's no way to control the order they run in. Second, that
doesn't cover the System user, or other users which are used only for
running services.

What bothers me most is that this used to be nice and simple, but was
broken for 'security' reasons. I would rather subst were just made
admin-only, or behave differently depending whether it was an admin or
a regular user running it.

 

[Pavel A.]

....
Two problems with using a logon script.
....

Correct. Thus, the mapping needs to be recreated in each *logon session*
(note: a service starts in a separate logon session even if it runs under some user account).

What bothers me most is that this used to be nice and simple, but was
broken for 'security' reasons.

Yep. Security isn't simple or easy. It often breaks existing code..
This helps keeping our jobs safe, among other things.

--PA

 

[cquirke (MVP Windows shell/user)]

jimrandomh wrote:

I must say I've avoided using Subst, Join, etc. as I'm always bracing
themselves to stop working - after all, many of these date from the
old MS-DOS 2, as workarounds for software written in the DOS 1 era
that doesn't understand directory paths.

Pavel A. wrote:

I still do not see the problem.. if everyone who uses the subst first runs a
script (globally - like a startup script for ALL users or a "wrapper" for
the applications that need this subst drive mapping..)

You can apply such a script as a Task set to run on logon, if not as
an item in the system (AllUsers, HKLM...Run) or account (Startup,
HKU...Run). But if you have to run it before each app, that's also
not as bad as it sounds - write a wrapper like this...

:: Call this MAP.BAT and put in the Path
@Echo Off
:: Do your mappings here...
Call %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
:: Clean up here

....then insert this into each shortcut's command line, e.g...

"M:\Some\Path\Blah.exe" /Extra /Stuff

....becomes...

MAP "M:\Some\Path\Blah.exe" /Extra /Stuff

------------------------ ---- --- -- - - - -

Forget http://cquirke.blogspot.com and check out a
better one at http://topicdrift.blogspot.com instead!

 

[cquirke (MVP Windows shell/user)]

On Sun, 12 Jun 2005 06:32:12 GMT, jimrandomh

Two problems with using a logon script. First, other items in the
startup folder and in hkey_local_machine/.../run need the drive mapped,
and there's no way to control the order they run in. Second, that
doesn't cover the System user, or other users which are used only for
running services.

The answer to both may be the same - a system-wide runpoint that is
serialized. I can't remember which one it is; I'd guess
HKLM...RunOnceEx or something like that, but I remember reading it.

The problem is whether this serializes only within itself, or before
everything else. If the former, then you may need something deeper,
such as a Wininit.ini (that runs very early).

Wininit.ini and RunOnce will both need to be re-seeded if they are to
run on every boot. You could re-assert them from any other
integration point or Task.

Even if you get this working on XP SP2, I'd give serious thought to
re-working your system to free it of dependency on Subst. Else you
may well face the same battles all over again in SP3, or LH.

------------------------ ---- --- -- - - - -

Forget http://cquirke.blogspot.com and check out a
better one at http://topicdrift.blogspot.com instead!