To help Google help you find this article, I should mention a few names I’ve come up for this scenario, search query names like, “multiple unwanted drive mappings”, and “windows multiple duplicate drive mappings” or even, “windows many cloned drive maps fault”.
None of the stuff in this article actually worked out in the end. Seems that underneath all the eye candy, Windows is still uselessly poor where it counts. Save yourself a lifetime of hassle and switch to Mac. You’ll never look back. That said …
A long, long time ago, I remember having a strange problem under Windows XP with Office 97. Machines around the office would have a single drive mapping to a samba network share — say, something like …
After booting, if I opened Windows Explorer soon enough, I’d see just that one mapping, as expected. Then, if I just sat there, doing nothing but staring at ‘Explorer, after a minute or so, that same mapping would start duplicating itself under every avaialble drive letter. Something like …
... all the way down to ...
Back then, it took ages to find the cause, which turned out to be some kind of bug in the Office 97 ‘parasite’ program, FindFast — a file indexer meant to make finding stuff quicker, which it actually did do, reasonably well, I guess. (Who on Earth forgets where they saved things though? :p) Completely removing FindFast made the problem go away back then and I hadn’t paid it the slightest thought over the ten plus years hence. (Never came across it again either, oddly enough!)
Fast-forward several major service packs of Windows XP, through Windows Vista (yikes!) and all the way up to Windows 7 (with the latest service packs as at 2011-01-01) and we find that, in true-to-themselves Microsoft form, the SAME fault still exists in the Windows7 buil-it Indexer service today. AMAZING, yet somehow not surprising. (I converted to Apple Mac as soon as they went Intel under BSD Unix — after some 20 years of Windows’ psych0-trauma’ing. To think — I used to actually believe that bugs like this were just an unavoidable part of owning a computer. I’m much wiser now though! :p)
Granted, this is one of those faults that seems to hardly ever show up anywhere on the planet — unless M$ have a secret pact with Google to remove all mention of it, somehow. But it’s not completely unheard of. I did manage to find ONE solitary post on the topic, from back in 2004 I think. Heck — it might even have be from me. (Don’t think so.)
So the fix under Windows7?
Go to the Control Panel, change the view to anything but ‘by Category’ and locate Indexing Options icon. Activate that and click the Modify button, lower left of the resulting window. Remove the tick from checkbox alongside Offline Files. (Searching for files you can’t even access? What’s with that anyway?) Problem solved.
I have to admit that I was quite astonished when this stab in the dark actually did cure the fault. Since I’ve been living with it for months (in a virtual machine I use for PCB design under Windows) and only just finally came up with this brain-storm-fluke of an idea, I thought I’d better blog about it somewhere, in hopes others with the problem can learn the answer too. Hope it helped … and that my sarcastic, cynical banter wasn’t too bad a thing to endure.
The problem came back. It no longer happened “just on its own”, as mentioned above. But some programs seemed to trigger it to happen again after opening the Choose File dialog box.
Suspecting the possibility of residual index data from before I disabled ‘Offline Files’ indexing, I click the Advanced button in the Index Options window and then the button to delete and rebuild the index. So far, the problem has not come back again. Yay \o/
I suppose that disabling the indexing service altogether (don’t know how in Win7 yet) might be the ultimate fix. But it seems a little ‘sledge hammer’ to me.
I Give Up
OK. I give up. It came back again the next morning. If you stumbled upon this post and did eventually find a permanent cure for this ancient incurable Windows BS bug … please do let me know by way of a comment. Thanks.