Windows 7 KB2670576 Update May Cause Renaming/Moving Issues

[Elmer]

An update released today (25-10-2011) may cause issues after being installed when you try to rename or move files/folders.

If I try to rename any folder in my system, I get "Could not find this item" with the choices "Try Again" and "Cancel". When I click "Try Again", it always succeeds. The same scenario happens when moving a file or folder.

There was another update in April 2010(?), KB980408, that caused the same issues for many people running Windows 7 64bit.

So if you find yourself in this position, you know what's causing it!!

Luckily, (a) Windows creates a restore point before installing KB2670576 and (b) It is an optional update, not a security update.

HTH.

 

[davehc]

This was a problem which occurred with an update, way back with Vista. The original fix still works for Windows 7 64Bit. I cannot comment on whether there is a similar fix for 32Bit.
Anyone who has the problem, run the attached reg into your registry, (just click OK to the message) No need for a reboot, it should work immediately.

Please. Usual warning. Make a backup of your registry and/or OS, before proceeding! Things go wrong!

Link Removed due to 404 Error

Later. Just wanted to express a thought. I am a dedicated Microsoft user, and have no serious arguments with the organisation. But I do find it astonishing, with their huge resources and expertise, that they can, three time over the past few years, send an update which causes the same malfunction.

 

[Elmer]

Thanks for the fix Dave.

TBH, when this happened to me yesterday, and as it had happened before, I immediately suspected one of the two updates I'd installed. As with KB980408 I just System Restored, never giving a thought to looking for a fix!!

I suspect that this is most likely (as it affects folder descriptions registry entries) to happen to people, like me, who are in to customising the look of there: system files/desktop/themes/folder names. There could well be a kick-back for all this inveterate tinkering!!

Update!!

After running the KB2670576 update again and re-booting as instructed, the error reared its ugly head again.

With a bit of investigation using the Folder Descriptions.reg file supplied by DaveHC, I found these five registry keys had been added to the registry:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{491E922F-5643-4af4-A7EB-4E7A138D8174}]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A302545D-DEFF-464b-ABE8-61C8648D939B}]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A990AE9F-A03B-4e80-94BC-9912D7504104}]

By adding the " - " to the beginning of the key paths and running the reg file removed the new registry entries. After another re-boot the update was installed and renaming/moving folders/files was back to normal.

 

[davehc]

For anyone interested, the problem is certainly linked, as Elmer suggests, to those of us who "tinker". However, in this particular case, I object to Microsoft's interpretation of the word. It is caused by the renaimg of file/folders, which do not follow the 8.3 convention. For instance, if you manipulate legacy programs, throught the officially offered Compatibility facility, thos programs, through their XP or other legacy facility, can put a .tild (that squiggly worm ¨), into a file or folder name, which windows 7 cannot accept. After four or five years, time MS sorted it!

 

[Saltgrass]

If I have the correct KB number, 2607576, it seems the registry entries you are looking at are the Library folders. On my system the entries are the same for before and after the update. And I have not seen the problem--yet..

So, two thoughts come to mind.

First, if you have altered something, it would have been interesting to see what those registry entries were prior to the update. Unless your changes had already removed them. The icons and such are set in the registry.

Secondly, since library folders or folders in the library are locations and not actual folders, is there any relation between which ones will not move or rename and the actual location of the folders in the library?

But you might be right about Microsoft wanting to bring the system back in compliance. Perhaps the feedback had suggested some problem was being caused by certain user changes.

 

[Elmer]

Yes, the added entries are Library related.

That's one of the things I tweak, hiding and/or removing library references!

As a luddite I prefer the old method of dropping my files in their final destination, not through the library "pseudo-location".
I had issues ages ago because I'd relocated my files, but now everything is set up as totally seperate from C:\ I've not yet had a situation where I thought "I wish I had libraries"!!

 

[davehc]

I also have my libraries disabled. You could well be right, other than what I read and posted, I am in the dark. But the problem also occurred in early vista - maybe not entirely related?
I have had that fix sitting in my Dbase for a while, but, this is the manula solution which was given by MS at the time (For Vista, but subsequently worked for 7):

1. Opena command prompt
2. Navigate to the folder that the object resides in.
3. Run "dir /a /x /p" to display the contents of the folder, including hidden files
(/a) and 8.3 filenames (/x).
4. Find the 8.3 filename of the object to the
left of the regular, long filename.
5. Run "ren <8.3 name>" to rename the object, "del <8.3 name>" to delete it if it's a file and "rd /s <8.3 name>" to delete it if it's a folder.

Note: If renaming to a long filename, make sure to enclose the long filename in quotations. If that fails, temporarily rename it to an 8.3 name and then rename it outside of the command prompt.