first of all I have to say that I really like Windows 7. I installed it on a 64bit System with Raid and the latest hardware and it installed very quickly with no problems and works very nicely.
Nonetheless, I have one problem: when I subst a directory with a drive and then try to copy files from that drive with the explorer, I get a 'file not found' error. When I copy the same file from the corresponding directory, it works fine. All other programs seem to work fine using the subst drive, though. I also cannot change the name of that drive as in Windows XP. Is this a security feature or a bug? I would find it very helpful if subst would work just as in Windows XP.
- Moved by Ronnie VernonModerator Monday, July 27, 2009 10:10 AM Focus (From:Windows 7 Miscellaneous)
Try running subst from the command prompt as the administrator. To do this, launch cmd as the administrator by right click on the command prompt icon, and select "Run as Administrator".
If you run subst as a regular user, it is only accessible in some case, and in others you get that "found not found error".
It would seem that the following would apply...
Services and Redirected Drives
INFO: Services and Redirected Drives
Each logon session gets its own set of drive letters; the filtered token is used in one logon session, and the elevated token is used in another. Two logon sessions, two sets of drive letters to manage...
PROBLEM: I have a new computer. I have a 2 gig partition dedicated to a DOS. The other partition is Windows 7. (I previously ran XP) Now when I boot-up into "pure" DOS (in the DOS partition) I can't establish substitute drives, although I have been using the same batch files for many years, so I know the syntax is correct. Now I get a message that, for example, G: is "parameter invalid".
Can anyone help? Thanks in advance.
REM --- Allow elevated and non elevated process to see / share all the drive mappings.
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"/v EnableLinkedConnections /t REG_DWORD /v 1 /F
REM --- Prevent the administative portion of the token from being stripped from
REM --- remote connections when using a local account.
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"/v LocalAccountTokenFilterPolicy /t REG_DWORD /v 1 /F
I know it seems to be a bug, and it's annoying, but it's by design. Quote from MSFT (somewhere):
Creating drive mappings with SUBST
When you create a drive mapping with SUBST, that mapping takes place in the context of the user account used to run the command. If you create a drive mapping as a regular user and try to access it with elevated privileges, the elevated-privilege process won't "see" the drive mapping. It can't, because the drive mapping has been done under a completely separate user account. This cuts both ways: If you create a drive mapping in the admin context and try to access it as a regular user, you can't. If you're running Vista, experiment with this yourself and see the results.
As tempting as it is to call this a bug, it's not, and it shouldn't be regarded as one. Vista is simply honoring the fact that drive mappings created in one user account are not typically accessed in another. If you rely on drive mappings in both the regular and elevated security contexts, you may need to run your drive-mapping scripts twice—once in a regular-user context and again in an elevated context—as a workaround.
I got around it by adding an extra subst line using 'runas' in my login script for the admin version.