Conflict between Subst'd drive and USB storage devices

[Guest]

For convenience, I use subst to map the G: drive letter to a subdirectory
under which I store all of my project folders. This caused no problems under
Win2000, but I was recently migrated to XP.

Now, if I insert a flash drive or hook up an external DVD-ROM drive, XP
assigns the drive letter that subst is using to the external device. At
first I couldn't figure out what was going on; the subst'd directory still
showed up and the external device simply seemed not to be there. But I
noticed the conflict in the hardware manager, and deleting subst mapping
caused the external drive to appear.

I assume that XP simply is not seeing the subst mapping, and uses G: because
it thinks it is the lowest available drive letter. Is this a bug in XP?

The only work-around I can come up with right now is to map subst to a
higher drive letter, leaving G: availabe for the external devices. I haven't
tried this yet, but it would probably work.

Any other suggested work-arounds? Is Microsoft aware of / working on a fix
for this?

 

[Chris Priede]

I assume that XP simply is not seeing the subst mapping, and uses G:
because it thinks it is the lowest available drive letter. Is this a
bug in XP?

It is known to happen. I am not sure whether Microsoft considers it a bug
that should be fixed:

http://support.microsoft.com/default.aspx?scid=kb;en-us;297694

The only work-around I can come up with right now is to map subst to a
higher drive letter, leaving G: availabe for the external devices. Any
other
suggested work-arounds?

Disk Management ("Start" -> "Run" -> "diskmgmt.msc") will usually see the
drive you plugged in and let you change the drive letter. It may even
remember it for the next time...

 

[Guest]

It is known to happen. I am not sure whether Microsoft considers it a bug
that should be fixed:

Well _I_ do! It bugs me that this problem did not exist in 2000, but does
in the putatively more advanced XP-Pro.

Disk Management ("Start" -> "Run" -> "diskmgmt.msc") will usually see the
drive you plugged in and let you change the drive letter. It may even
remember it for the next time...

Unfortunately I am in a secure computing environment and do not have
sufficient rights to run diskmgmt.msc. I did verify that substing to a
higher drive letter makes the problem go away. Unfortunately that kills a
lot of my data associations, so I'll probably just un-subst the drive
periodically when I need to plug in an external device.

Thanks for your help Chris!

 

[78 and counting]

Well _I_ do! It bugs me that this problem did not exist in 2000, but does
in the putatively more advanced XP-Pro.


Unfortunately I am in a secure computing environment and do not have
sufficient rights to run diskmgmt.msc. I did verify that substing to a
higher drive letter makes the problem go away. Unfortunately that kills a
lot of my data associations, so I'll probably just un-subst the drive
periodically when I need to plug in an external device.

Thanks for your help Chris!

Take the USB drive to a computer where you can assign a letter to the USB
drive.
When you connect it to the computer without Administrator rights it should
pick up that new letter provided there is no conflict because the letter you
pick is already in use.

At least that is the way it works on my two computers.

YMMV

 

[cquirke (MVP Windows shell/user)]

For convenience, I use subst to map the G: drive letter to a subdirectory
under which I store all of my project folders. This caused no problems under
Win2000, but I was recently migrated to XP.

Now, if I insert a flash drive or hook up an external DVD-ROM drive, XP
assigns the drive letter that subst is using to the external device. At
first I couldn't figure out what was going on; the subst'd directory still
showed up and the external device simply seemed not to be there. But I
noticed the conflict in the hardware manager, and deleting subst mapping
caused the external drive to appear.

I assume that XP simply is not seeing the subst mapping, and uses G: because
it thinks it is the lowest available drive letter. Is this a bug in XP?

Yep. Same thing happens with LAN shares, so the policy is to keep
both LAN share and Subst letter mappings to "high" letters.

The only work-around I can come up with right now is to map subst to a
higher drive letter, leaving G: availabe for the external devices. I haven't
tried this yet, but it would probably work.

It does work. The other thing is to map the device to a higher letter
via Admin Tools, Storage etc. but as there's one constant Subst,
and an unbounded number of potential new drives and devices, I'd
treat the low letters as the immovable object and move the mappings.

Any other suggested work-arounds? Is Microsoft aware of / working on a fix
for this?

I've no idea on the state of clue where drive letter assignment is
concerned, but it's always been an ugly issue. MS-DOS and Win9x were
ugly but different; they'd avoid overlaying one thing over another,
but were far more rigid in allocating letters in the set order that
was based on when the entities were discovered - you could change the
letter for LAN shares, Substs and optical drives, but that was it; any
and all HD volume assignments were cast in stone.

There are safety/security risks associated with enumeration rather
than true identification, in that different things may ennumerate to
the same letter and thus inherit inappropriate settings.

For example, I reviewed a Win9x-era fingerprint reader, and the
associated "private spaces" encrypted-container-file-as-"drive"
software that went with it. Local legal customs forbade testing with
freshly-amputated fingers, but one risk I did pick up was that if I
created a "private space" as G: and shared G: on the LAN, then if your
"private space" also mapped to G:, I could read it through the share.

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

The most accurate diagnostic instrument
in medicine is the Retrospectoscope

 

[Guest]

I am experiencing the same "bug" with Server 2003 SP1 when I run 'net use'
from a logon script and then try to insert a flash drive. You would think
that Microsoft would not be content with the "just don't do it" approach, and
implement some checking between Drive manager and command line tools.

 

[Uwe Sieber]

I am experiencing the same "bug" with Server 2003 SP1 when I run 'net use'
from a logon script and then try to insert a flash drive. You would think
that Microsoft would not be content with the "just don't do it" approach, and
implement some checking between Drive manager and command line tools.

Wow, you reactivated a nine month old thread

Meanwhile there is a 3rd party solution. My USB drive
letter manager, USBDLM:
http://www.uwe-sieber.de/usbdlm_e.html

The latest release requires no configuration. It detects
when an USB drive got the letter of a network share of
the currently logged on user and remounts then the drive
to the next letter that is really free.


Greetings from Germany

Uwe