bug in Win-XP-Pro with flash-drive and subst

[David Cook]

There seems to be a bug in Win-XP Pro (SP2), when drive-letter
to be assigned to a hot-plugged flash-drive collides with the same-letter
assigned to a SUBSTituted drive.

Steps to reproduce:

(1)Hot-plug a flash-drive into a USB-port. Let's say the device
gets assigned the letter E: This works normally and the flash-drive
works fine. (My flash-drive happens to be a Lexar Media 'Jump-drive'
that is 128-MB in size.)

(2)Un-plug that flash-drive, so that the letter E: is no longer visible in
the
file-explorer as an assigned drive letter.

(3)Now create a cmd-script (e.g. named 'login.cmd') that contains the
command:
subst E: C:\
and create a shortcut for cmd-window. In the 'target' for that cmd-window
shortcut, append the cmd-line switch:
/k login.cmd
so that this script gets run anytime that this cmd-window is launched.

(4)Move that shortcut into the user's 'startup' group (so that now the E:
drive will get created (via the SUBST cmd) when the user logs in.

(5)Now, once this logged-in user ever subsequently tries to insert this
flash-drive into a USB-port, the system will NOW no longer make the
flash-drive accessible. It seems to have 'remembered' E: so rather than
assign the next available drive-letter (e.g. F to the flash-drive, it
instead ERRONEOUSLY tries to re-claim E: as its drive-letter.
(Code-stream seems to execute partially...the drive E: seems to
erroneously get its 'type' changed from 'local drive' to 'removable drive',
but the drive E: correctly retains its mapping to C:\ (since the SUBST
is still in effect).

However, the flash-drive is NOW not accessible. I can find no workaround
or method to get the flash-drive to mount for that user. (Other than to
remove the SUBST and use some OTHER drive-letter for the SUBST.)
[Using a different-drive letter for the SUBST is not desireable, as other
external scripts on the groups development-server would have to be
changed.]

[Is this earlier erroneously remembered claiming of drive E: being
remembered
in the registry somewhere? If so, then maybe deleting that registry
entry would workaround this problem?]

Regards...

Dave

 

[Pavel]

So that you know, this is not a unique problem to SUBST. Same situation
arises when any type of device, which uses a drive letter that is assigned
trough the use of Disk manager. While such device is active there is a drive
letter and no drive letter when such device is unplugged. If you now create
a mapped drive that uses same drive letter and then enable (plug it in) the
original device, only the mapped drive will be shown.

 

[Guest]

bit of a no brainer really, simply use the disc management tool to assign an
available drive letter to the removable drive, it takes like 2 seconds and
the drive is usable

good luck

 

[HeyBub]

There seems to be a bug in Win-XP Pro (SP2), when drive-letter
to be assigned to a hot-plugged flash-drive collides with the
same-letter assigned to a SUBSTituted drive.

Steps to reproduce:

Similar to the complaint of the granny lady who tells the cops: "If you put
a stool in the bathroom so you can lean out of the window, and with this
mirror pointed just so, you can see my neighbor exposing himself."

 

[Pavel]

Steve,

That is exactly what will create a problem. If the removable drive is
assigned a drive letter using the disk management to let's say drive P. Now
if you remove this removable drive, the letter P seem to be available so
when you then use the SUBS or MAP Network Drive and reuse this drive letter,
everything seem to be ok untill you plug in the removable drive. The
removable drive will not seem to exist and no next free drive letter will be
assigned to it.
Since Subs is a CMD command, there will be no inditaction as to what drive
letters are available. The Map network drive does offer choice of the drive
letters.

 

[David Cook]

Yes, I pretty much expected that the problem was not unique to SUBST.

To me, the question is 'do they ever plan to FIX it?'

(Ya gotta love M$...they have a reputation of declaring such things
a feature rather than a bug. It's only a bug if THEY say it is. Sigh.)

Dave

So that you know, this is not a unique problem to SUBST. Same situation
arises when any type of device, which uses a drive letter that is assigned
trough the use of Disk manager. While such device is active there is a
drive letter and no drive letter when such device is unplugged. If you now
create a mapped drive that uses same drive letter and then enable (plug it
in) the original device, only the mapped drive will be shown.

--
Pavel

There seems to be a bug in Win-XP Pro (SP2), when drive-letter
to be assigned to a hot-plugged flash-drive collides with the same-letter
assigned to a SUBSTituted drive.

Steps to reproduce:

(1)Hot-plug a flash-drive into a USB-port. Let's say the device
gets assigned the letter E: This works normally and the flash-drive
works fine. (My flash-drive happens to be a Lexar Media 'Jump-drive'
that is 128-MB in size.)

(2)Un-plug that flash-drive, so that the letter E: is no longer visible
in the
file-explorer as an assigned drive letter.

(3)Now create a cmd-script (e.g. named 'login.cmd') that contains the
command:
subst E: C:\
and create a shortcut for cmd-window. In the 'target' for that
cmd-window
shortcut, append the cmd-line switch:
/k login.cmd
so that this script gets run anytime that this cmd-window is launched.

(4)Move that shortcut into the user's 'startup' group (so that now the E:
drive will get created (via the SUBST cmd) when the user logs in.

(5)Now, once this logged-in user ever subsequently tries to insert this
flash-drive into a USB-port, the system will NOW no longer make the
flash-drive accessible. It seems to have 'remembered' E: so rather than
assign the next available drive-letter (e.g. F to the flash-drive, it
instead ERRONEOUSLY tries to re-claim E: as its drive-letter.
(Code-stream seems to execute partially...the drive E: seems to
erroneously get its 'type' changed from 'local drive' to 'removable
drive',
but the drive E: correctly retains its mapping to C:\ (since the SUBST
is still in effect).

However, the flash-drive is NOW not accessible. I can find no workaround
or method to get the flash-drive to mount for that user. (Other than to
remove the SUBST and use some OTHER drive-letter for the SUBST.)
[Using a different-drive letter for the SUBST is not desireable, as other
external scripts on the groups development-server would have to be
changed.]

[Is this earlier erroneously remembered claiming of drive E: being
remembered
in the registry somewhere? If so, then maybe deleting that registry
entry would workaround this problem?]

Regards...

Dave

 

[Bob I]

The same situation exists with Network drives being mapped and
Autoassignment of local drives. At this point the USER is in control.
Would you prefer MS removed SUBST?

Yes, I pretty much expected that the problem was not unique to SUBST.

To me, the question is 'do they ever plan to FIX it?'

(Ya gotta love M$...they have a reputation of declaring such things
a feature rather than a bug. It's only a bug if THEY say it is. Sigh.)

Dave

So that you know, this is not a unique problem to SUBST. Same situation
arises when any type of device, which uses a drive letter that is assigned
trough the use of Disk manager. While such device is active there is a
drive letter and no drive letter when such device is unplugged. If you now
create a mapped drive that uses same drive letter and then enable (plug it
in) the original device, only the mapped drive will be shown.

--
Pavel

There seems to be a bug in Win-XP Pro (SP2), when drive-letter
to be assigned to a hot-plugged flash-drive collides with the same-letter
assigned to a SUBSTituted drive.

Steps to reproduce:

(1)Hot-plug a flash-drive into a USB-port. Let's say the device
gets assigned the letter E: This works normally and the flash-drive
works fine. (My flash-drive happens to be a Lexar Media 'Jump-drive'
that is 128-MB in size.)

(2)Un-plug that flash-drive, so that the letter E: is no longer visible
in the
file-explorer as an assigned drive letter.

(3)Now create a cmd-script (e.g. named 'login.cmd') that contains the
command:
subst E: C:\
and create a shortcut for cmd-window. In the 'target' for that
cmd-window
shortcut, append the cmd-line switch:
/k login.cmd
so that this script gets run anytime that this cmd-window is launched.

(4)Move that shortcut into the user's 'startup' group (so that now the E:
drive will get created (via the SUBST cmd) when the user logs in.

(5)Now, once this logged-in user ever subsequently tries to insert this
flash-drive into a USB-port, the system will NOW no longer make the
flash-drive accessible. It seems to have 'remembered' E: so rather than
assign the next available drive-letter (e.g. F to the flash-drive, it
instead ERRONEOUSLY tries to re-claim E: as its drive-letter.
(Code-stream seems to execute partially...the drive E: seems to
erroneously get its 'type' changed from 'local drive' to 'removable
drive',
but the drive E: correctly retains its mapping to C:\ (since the SUBST
is still in effect).

However, the flash-drive is NOW not accessible. I can find no workaround
or method to get the flash-drive to mount for that user. (Other than to
remove the SUBST and use some OTHER drive-letter for the SUBST.)
[Using a different-drive letter for the SUBST is not desireable, as other
external scripts on the groups development-server would have to be
changed.]

[Is this earlier erroneously remembered claiming of drive E: being
remembered
in the registry somewhere? If so, then maybe deleting that registry
entry would workaround this problem?]

Regards...

Dave