Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sbsp2]

Just started using MC18 and it's not seeing my 4 SUBST drives (virtual drives from folders on my C: drive).  Been using MC13 for 5+ years (probably) and never had this issue.  Is there something I can do/change in MC18 to get it to see the SUBST drives?

(using Windows 8 Pro)

[Matt]

In what part of the program in particular is the program not seeing these drives?

[sbsp2]

Under Drives & Devices -> Explorer.  My J: thru M: virtual drives are not showing up.   I have all my MP3s on J:, so I can't play them (using the J: pathing).

[Matt]

Does it work to import the files and play them in the library, or are they invisible to import as well?

[sbsp2]

Import does not see J: thru M: either.  MC18 can see the host drive (E:) where the folders are for J: thru M:.

Just weird how MC18 can't see the any subst virtual drives.  I've tried deleting and re-adding them from the command prompt SUBST command and MC18 still does not see them.  Windows Explorer does fine.

[sbsp2]

(bump) No idea what I can try next?  Is this just an Windows 8 issue, perhaps?  Should I try running MC18 in compatibility mode (like Win 7 or something)?

[Matt]

It's possible Windows 8 changed something here.  I know it changed how it classifies hard drives through WMDM.

Let us test on our end and follow up next week.

If anyone else has any insight, it would be appreciated.

[mbagge]

I have found this on Microsoft Technet.
http://social.technet.microsoft.com/Forums/en-US/w7itproperf/thread/3d13d9ce-1548-45e4-8873-bad3869d6cd2

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.

It seems that this behavior is by design.

[Hendrik]

That post only refers to creating the subst drives under another user, which i dont think applies here.

[mbagge]

Some parts of MC do require elevated rights to run. I cannot tell if this applies here, but it for sure could explain the behavior.
The referred article also includes changes in Registry that addresses this.
And creating the subst drive in an elevated rights context might just make it work. I cannot test this because I do not have the Windows 8 / MC18 combination installed.

[sbsp2]

Well, that worked!!!  I created the SUBST drives by running command prompt as Administrator and then MC18 could see the SUBST drivers.  BTW - My user account is an Administrator, but that doesn't seem to matter.

[sbsp2]

Ok.  I have to admit at some point early on, I changed the MC18 shortcut I was using to be 'Run as Administrator' (trying to see if I could get rid of the UAC warning everytime I run MC18) and this must be the real deal (problem).  Because, now my local (normal) login cannot see the SUBST drives in Windows Explorer (unless I run the Windows Explorer as Administrator).  So, sorry to bother everybody with 'my issues'.