The most impossible problem ever... assigning USB drive a letter!

bexamous

[H]ard|Gawd
Joined
Dec 12, 2005
Messages
1,670
I HATE Windows... at work E: on everyone's system is mapped to something for some god forsaken reason. C: is harddrive, D: is cdrom. Plug in USB key... C taken, D taken, E taken.... USB Key gets..... E! DUH! COMMON SENSE RIGHT?

Why the hell does Windows do this crap? Manually go change it to F or some other unused letter. Every USB key I EVER put in my computer I gotta jump through more hoops just to get it to a usable letter.

Anyways.
 
Yeah, that a limitation in Windows. It just doesn't look at the network drive letters when assigning a new device.

Here's the kicker: Vista doesn't fix this. Are they ever going try to fix long standing problems like this?
 
what company uses anything higher up than H:? (for home drives)

Propose a change to the login script and change the E: mapping to something else.
 
the last company I worked for used F for the main share. Drove me nuts. I tried to get that changed for years, but it was decided it would cause the users to much heartache.

I sure loved having to go reassign drive letters every time someone tried to use a memory stick or camera...
 
That's why I use U, as in User. I have a few people with card readers, so they have their internal drives, the card reader, USB flash drives, etc.
 
No issues with thumb drives here.
A/C/D/E are local
G/H/I/J/K/L are mapped drives for me (admin)
I plug in one thumb drive, I get F. I plug in my 2nd one it pulls M. I plug in my third drive ( external HDD) and it pulls N.

Is there really supposed to be an issue with mapped drives and plugging in thumb drives?
 
use disk management to assign a drive letter to the USB drive, it should remember the next time once it has been set.
 
use disk management to assign a drive letter to the USB drive, it should remember the next time once it has been set.

That's exactly what I do and I don't have any problems with it...
 
Used to have that problem here, haven't had any issues since installing USBDLM into the image. Only free for private and edu use, though.

Definitely one of the stupider issues that Microsoft has known about for a long time.
 
It doesn't happen for everyone, all the time. I'll give you an example. If you have a mapped drive set to G:, and your internal drives take up C, D, E, and F, you will often lose your mapped drive, as it gives G to the inserted flash drive.

We all know you can go and reassign it a new letter in disk management. The problem is, in some situations, in some case, that new assignment doesn't stick.
 
Not to be an idiot, but why don't people just assign different letters to shares?

In an environment with many users, it would be an inconvenient switch, but I'm curious why people don't just map to x,y,z from the beginning since M$ knows about the problem, but so do we. They have the responsibility to fix it, but if the workaround is already well known then there really need not be a problem-just an inconvenience.

In my home network, I stay way the hell out of Windows' way with stuff mapped to N (NAS), S (shared storage), Z (zip/rar/etc).
 
Not to be an idiot, but why don't people just assign different letters to shares?

It's not necessarily your choice - in a business environment, shares will often be set up by a logon script, and even if you were to change them every login, you'll find that everyone assumes you have the standard share setup and whenever anyone sends a link it will break. Changing the logon script may result in dozens of people phoning up the IT administrator demanding to know where all their files have gone and why their spreadsheets are broken etc.
 
If the USB drive was attached and assigned a drive letter before that drive letter was mapped to a network share, when the USB drive is reattached after the drive letter is assigned to the share, the USB drive takes priority and retakes the drive letter. As soon as it is unplugged, the drive letter goes back to the share.

This is done so that any programs on the USB drive that may be dependent on drive letter will work properly.

I do the following to make sure I never have that issue.

1. Make and empty folder called "drives". I ususally put it in my desktop directory.
2. Make a sub folder under drives for the USB drive.
3. Connect the USB drive.
4. Go to disk managment and remove the drive letter assigned to the USB drive.
5. Assign the USB drive to the folder created in step 2.

You have to create a separate subfolder for each USB drive.

No more drive letter assignment problems. Insert the USB drive and access the files through the subfolder under "drives".

If you are in an environment where I'm scripting your drives, and you remap them, I'll put them back in the standard config for your department the next time you log on. With 30,000 users in hundreds of departments, I need the helpdesk to be able to figure out where the end user's problem is when they say my drive q: is reporting out of disk space without having to take the time to remote into a machine and look for themselves because the end user is barely capable of turning their workstation on. An Excel spreadsheet with a list of drives by department makes it easy. :)
 
Why don't admins just assign from bottom up? Well, it has to do a lot with legacy apps. For instance, those of us...blessed...with a netware network HAVE to use f:. Or at least used to, I don't know if that's still required with netware 6.5, but I'd bet it is.

Further, we still use software that was setup many many moons ago to pull it's data from the g and h drives. And the kicker? It's hard coded into the database, so unless we want to dump the data, we can't reassign those drive letters.

What's worse is that to manage disk devices, you need to be local admin ( or power user ), which means regular users are unable to fix this problem. And because it's the higher ups who are using these bloody things, claims of security fall on deaf ears.

Welcome to corporate culture. MS needs to get off their ass and fix this problem.
 
Welcome to corporate culture. MS needs to get off their ass and fix this problem.

Uh, its not a problem, this behavior only occurs if the USB drive was assigned the drive letter that is eventually used by a share, before the share was in place.

This behavior occurs for exactly the same reason as your legacy drive mappings. If something was configured to run from the USB drive, and a new drive letter was assigned, it would break when the USB drive is present.
 
"Uh, its not a problem, this behavior only occurs if the USB drive was assigned the drive letter that is eventually used by a share, before the share was in place."

First of all that is not true. Second of all lets say it is true, how does that change the fact that it is a problem?

Here is how simple the problem is:

"I plug in a USB Key. It is assigned a letter in use."

As long as this happens there is a problem.

Perhaps another way to think about this of than OS design point. Here is some very basic logic:
If a user plugs in a USB Key they intend to access it.
Therefore, it should be assigned a letter that makes it accessible.

Windows = fail.
 
"Uh, its not a problem, this behavior only occurs if the USB drive was assigned the drive letter that is eventually used by a share, before the share was in place."

First of all that is not true. Second of all lets say it is true, how does that change the fact that it is a problem?

Here is how simple the problem is:

"I plug in a USB Key. It is assigned a letter in use."

As long as this happens there is a problem.

Perhaps another way to think about this of than OS design point. Here is some very basic logic:
If a user plugs in a USB Key they intend to access it.
Therefore, it should be assigned a letter that makes it accessible.

Windows = fail.

It is an issue that they simply haven't addressed, one among many. If they choose to address it, then good. All I know is that this is still an issue with Vista, so they haven't even fixed it there.

Just like the copy issue. (Why can't they at least put in a "skip this file and continue" button when a copy comes across a file that is in use?) That has been an issue since Windows 3.1. There are so many, I couldn't list them all. That's life, just live with it.
 
It is well documented that common practice is to use mapped drives starting from Z: and working your way up to avoid conflicts such as the one you are experiencing.
 
Yeah, well, good practices aren't always adopted. For instance, my company had an admin a while back that insisted they didn't need SMS to deploy software and chose to use group policy through OU's in AD. We are still trying to clean up that mess.
 
No issues with thumb drives here.
A/C/D/E are local
G/H/I/J/K/L are mapped drives for me (admin)
I plug in one thumb drive, I get F. I plug in my 2nd one it pulls M. I plug in my third drive ( external HDD) and it pulls N.

Is there really supposed to be an issue with mapped drives and plugging in thumb drives?

Yes
 
Back
Top