Do you really have to rebuild the index every
time you delete a file so that the search results are not 'out of date'?
Shouldn't have to for any reason I can think of. Could be a carry over
of another bad bug that never seems to get fixed in Explorer where at
times it will nag "you can't do that" claiming a file is "in use"
(when for sure it isn't) and stuff like that. That's why I started the
memory leak thread, but of course the kiddie squad just has to pretend
I don't know what I'm talking about. ;-)
Anyhow, I just tried an experiment and got weird results with Search.
I began by emptying the Recycle Bin. Next I "deleted" 45 files all
contained the word Calvin somewhere in the file name, and moved 6 more
files having Calvin in their name to a different drive, then tried a
couple of different searches to see how Vista would do.
If I do an advanced search, tell Vista to look "everywhere" check
"include non indexed, hidden and system files it correctly returns the
6 files with Calvin in their name that I moved to my "H" drive. It
reported none of the files I dragged to the Recycle Bin.
So far, so good.
Now trying a simple search for Calvin which limits the search to only
indexed folders on my root drive C, when I NEVER put any Calvin files
at any time it finds a shortcut in the roaming folder. The only
problem is I didn't make any such shortcut, and if I did I sure
wouldn't have put in there. Surprise it really isn't a shortcut in the
traditional sense.
Now put your hip boots on. (from MSDN)
In Vista, default user data and system data have changed. For example,
user data that was previously stored in the %SystemDrive%\Documents
and Settings directory is now stored in the %SystemDrive%\Users
directory. In order to minimize the amount of application
compatibility problems users would experience due to the change in
folders names, such as C:\Documents and Settings moving to C:\Users,
Microsoft employed junction points. These junction points make it so
that hard coded reads and writes to legacy file locations would
automatically go to the correct new location without changing the
application.
Junction points can be identified as follows:
They have the FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_HIDDEN, and
FILE_ATTRIBUTE_SYSTEM file attributes set. They also have their access
control lists (ACLs) set to deny read access to everyone.
Ed note:
Not apparently to Windows build-in search function, which explains why
it "hit" one of these junctions and showed it as a shortcut to the
Calvin folder. Want to have some fun, click Start, then just type in
'roaming' and watch Vista go nuts.
Remember Calvin? Well, like I said except for 6 files moved to "H" all
the remaing Calvin files got dragged and dropped in the Recycle Bin.
Not according to roaming. If I look at the results of the search using
'roaming" guess what... all the Calvin files (plus thousands of
others) are back in their original folder I put them with a time stamp
of a couple days ago when I first got them. Interesting to say the
least. Actually, that's not totally accurate. They aren't back in the
sense they can been seen with Explorer, no, they simply exist in some
defacto limbo when or if they go away I have no idea, non the less
Vista knows how to get them back, which means there got to be some
reference in the Registry, which create a entirely new security risk.
Here's why that's true. Just for fun I looked at some of these roaming
links and many were to applications, some I tested and deleted, others
to files I either worked on or moved elsewhere.
Now get this. I scan the list of 'roaming' files and hit on a music
video of some kids singing "You never walk alone". I remember
downloading this on 3/12, but I had renamed and moved it. However to
the "system" it still has a hot link in the roaming area under the
original file name. Just for the heck of it, I clicked on the link
from the roaming search window and the file still plays, so at the
least all these blind links eat up lots of disk space.
Anyhow, forgot that, that problem is for another day. To continue on,
applications that call out a specific path can traverse these junction
points if they have the required permissions. However, attempts to
enumerate the contents of the junction points will result in failures.
It is important that backup applications do not traverse these
junction points, or attempt to backup data under them, for two
reasons: Doing so can cause the backup application to back up the same
data more than once. It can also lead to cycles (circular references).
To more fully understand what's really happening you need to view the
movie staring the two Microsoft authors of UAC. You'll then learn how
tokens get created which can bypass UAC's nag screens to allow
processes through that otherwise would result in nag screens. Vista by
design tries to protect itself, ie, critical system files like the
kernel. The downside is this can have unanticiped consequences, more
so, if you start trying to do "system level" events, even something as
routine as copy/moving/renaming or trying to delete files. So one
downside seems to be Vista can when searching find and return juction
points and show them as "hits" when searching, even though they are
only internal reference points, and not actual user accessible files.
However if you search a different way things work normally.
Conclusion: Vista needs work. Lots of work. My question goes to the
beta testers. Come on guys, how did you miss all this?
