File Search doesn't work right

  • Thread starter Thread starter Guest
  • Start date Start date
I was finally able to check a couple more systems, and every Win2K SP4
system I've checked displays the same behavior. Search does not display
.dll or .exe files in folders subordinate to WINNT except for AppPatch and
the uninstall folders. No other file extension seems to be affected.

... and now I may have found the cause and the explanation for why some
systems do not exhibit the described behavior. The next folder following
AppPatch in WINNT on all of these systems is "assembly", which may be
related to .NET. The assembly folder contains a desktop.ini file which
causes Explorer to provide a special view of the contents. Somehow that
process interferes with the identification or listing of .dll and .exe
files. If the assembly folder is not present, or if the desktop.ini is
removed or renamed, searches for these files behave normally.
Click to expand...

Excellent investigative work.

So is it the desktop.ini file that causes the problem? Does deleting
it solve the problem? (I'm not in front of my Windows 2000 machine
right now.) Is it even OK to delete it -- or would that cause other
problems? Maybe it's not the desktop.ini that is the problem, because
other folders like the Fonts folder have a desktop.ini, and the Find
functionality handles that one fine.

What we have here is a bug. Unfortunately, there doesn't appear to be any
practical circumvention other than using something other than Explorer to
locate these files.
Click to expand...

Yeah Windows 2000 only gets security updates now. When you break
something as basic as Find though, maybe they should make an exception
and fix that.
 
Excellent investigative work.
Thanks.

So is it the desktop.ini file that causes the problem? Does deleting
it solve the problem? (I'm not in front of my Windows 2000 machine
right now.) Is it even OK to delete it -- or would that cause other
problems? Maybe it's not the desktop.ini that is the problem, because
other folders like the Fonts folder have a desktop.ini, and the Find
functionality handles that one fine.
Click to expand...

Deleting or renaming desktop.ini solves the problem, but doing so may
cause others. I don't know what effect removing it may have. The content
is fairly simple:

; ==++==
;
; Copyright (c) Microsoft Corporation. All rights reserved.
;
; ==--==
[.ShellClassInfo]
CLSID={1D2680C9-0E2A-469d-B787-065558BC7D43}
ConfirmFileOp=1
InfoTip=Contains application stability information.

Other folders do indeed have desktop.ini files -- there are 53 on my
system -- but the contents vary. Removing desktop.ini may cause problems
in using or updating the files in this folder. I know that removing
desktop.ini from the Fonts folder causes it to lose some of its
functionality. Evidently the CLSID entry is what invokes the magic. I
suspect that the handler for this CLSID is invoked when a search enters
the assemply folder and a bug in the handler presents the search from
continuing.
 
Deleting or renaming desktop.ini solves the problem, but doing so may
cause others. I don't know what effect removing it may have.
Click to expand...

I have found a few pages where people mention deleting (or renaming)
the desktop.ini file in the %windir%\assembly folder. Seems like the
only functionality you will lose is drag and drop installation of .NET
assembly files (although I won't guarantee that).

http://blogs.msdn.com/cumgranosalis/archive/2005/10/03/476275.aspx
http://geekswithblogs.net/pavelka/Default.aspx

The content is fairly simple:

; ==++==
;
; Copyright (c) Microsoft Corporation. All rights reserved.
;
; ==--==
[.ShellClassInfo]
CLSID={1D2680C9-0E2A-469d-B787-065558BC7D43}
ConfirmFileOp=1
InfoTip=Contains application stability information.

Other folders do indeed have desktop.ini files -- there are 53 on my
system -- but the contents vary. Removing desktop.ini may cause problems
in using or updating the files in this folder. I know that removing
desktop.ini from the Fonts folder causes it to lose some of its
functionality. Evidently the CLSID entry is what invokes the magic. I
suspect that the handler for this CLSID is invoked when a search enters
the assemply folder and a bug in the handler presents the search from
continuing.
Click to expand...

I suspect you are right.

That CLSID handler must have been installed with .NET, so that gives
us hope that the bug can be fixed, since it would be a .NET update and
not a Windows 2000 update. But then again, Windows XP does not
exhibit the problem, so there is something different between Windows
2000 and XP.
 
I have found a few pages where people mention deleting (or renaming)
the desktop.ini file in the %windir%\assembly folder. Seems like the
only functionality you will lose is drag and drop installation of .NET
assembly files (although I won't guarantee that).
Click to expand...
http://blogs.msdn.com/cumgranosalis/archive/2005/10/03/476275.aspx
http://geekswithblogs.net/pavelka/Default.aspx
Click to expand...

Thanks for that. I've decided to rename Desktop.ini and see what happens.
I suspect that the drag-and-drop installation feature is of interest
mainly to .NET developers, which I'll never be.
 
Back
Top