none
Problem with 'subst'. Bug or Feature?

    General discussion

  • Hi,

    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.
    Monday, July 27, 2009 8:08 AM

All replies

  • Hi,

    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".
    Tuesday, July 28, 2009 4:15 PM
  • It seems that subst needs to be run twice: one for the current user, and one for the administrator. This seems to be a bug, admin's subst should apply to the current user also.
    Tuesday, July 28, 2009 5:02 PM
  • Hi,


    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...
    Tuesday, July 28, 2009 10:29 PM
  • 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.

     

    Monday, July 05, 2010 3:08 PM
  • I get this same problem too.
    Wednesday, October 20, 2010 5:31 PM
  • Try these:

     

    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

    Monday, November 22, 2010 9:39 PM
  • 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. 

    Tuesday, September 13, 2011 1:33 AM