Is Windows Vista index-based full-text search powerful enough?

[DevilsPGD]

In message <[email protected]> "Dave Wood [MS]"

- Generally you just type to make a search happen, there isn't a button to
start searching. As soon as you press a key we start searching so you don't
have to type the whole of a word you are looking for.

This makes sense since the hit to narrow a query isn't usually a big
deal assuming the index isn't too massive to begin with.

Any chance this can be configured (or a wait time to let the user type a
bit more?) -- It does start to drag a bit on a really slow system while
the index searches faster then the GUI notices the user typing.

The exception to this
is when you have the advanced search checked in which case there is a Search
button. But note that the search button converts your advanced search
options to a query string and puts it in the main search box, which triggers
a search.

Yup -- Very cool implementation, since it "teaches" the observant user
about how to repeat that search without using the GUI.

- Clicking the red 'X' should stop a search - if that doesn't work let me
know.

- As far as I can tell *.* works the same as * in filename searches.

It should be similar, since the * wildcard matches on "." as well.
However, *.* wouldn't match a file without an extension.

The wildcards * and ? do work on other properties also.

My co-worker Jonas has a
couple of blog entries which explain some of this:
http://blogs.msdn.com/jonasbar/default.aspx

Interesting info, thanks (to the poster as well as you for bringing it
up)

 

[Guest]

I do realise that my use of a computer is not the use a majority of users
use it for. Got no grandkids (or even previous versions of it, called kids)
therefore have no photos of them. Some of the time I search for system
files - others my very large self generated knowledge base filled with names
of system files.

I understand that Windows is geared to grandparents and corporate slaves.

But after the needs of these core groups are met surely some effort can be
spent at the margins on making it useful to other groups.

I use a mouse. I keep my keyboard out of the way unless typing longish
messages like this. I use start-run all the time because I type once and
click many times. A history is far more useful than autocomplete as one can
use a mouse to select a previous search.

I've been aware since 95 about saved searches but have not found a use for
them in the last 12 years. Partly because the Start In path of a saved
search wasn't reliable (50% of the time it didn't work). Virtual folders was
useless as a concept as it wasn't reliable.

I found turning off Indexing makes Advanced Search remember Search System
and Hidden and also defaults to Everywhere. Just what I want. As I store
data categorised in sub folders and right clicking - Search defaulted to not
ticking System and Hidden (I have lots of folders and files with these
attributes for some long ago development project).

I normally want to specify exactly what to search for as I am mostly
searching for technical information like program code. So I want to restrict
search to files likely to contain the code (.h, bas, or hta). There is no
field for this in contents meaning It is difficult to cut and paste using a
mouse only.

So I paste shell32.dll, into search. Search then annoyingly starts but it is
searching for the wrong thing. I know this. Because I want ext:*.bas
content:shell32 and it may be zipped up outside of my user profile. The user
experience of V8 cars is far more relaxing than 4 cylinders because people
don't feel like they have to help the car by useless emotional exertion.
Same with search, I can't but help hear the drive churning, and I know it is
not doing my search as I haven't told it completely yet. I understand there
is little time penalty, but there is one as display of icons is a reasonably
slow thing. It's a psychological thing.

I would call the Start menu search a filtering operation rather than a
search (I used to love auto filter in access). It is perhaps appropriate to
do it live there. Although anything I want is pinned or in Start Run.

I am the biggest expert on keyboards in windows you will ever meet - because
you're mob only have experts in various sub sections of keyboard use. I'm
not anti keyboard. At times I operate windows with only a keyboard.

How about integrating Help and the PSDK infoviewer into search - you MSs
always do things half heartedly.

That blog entry was good. He doesn't seem to write often. Nor has anyone
commented. Perhaps he should reopen comments, write a new article, and ask
Raymond to spruik it. Perhaps you could become famous like Raymond if you
started blogging too.

Personally I believe your approach to infomation retrieval is conceptually
flawed if useful. I don't think search is the way to go untill the OS and
technology can categorise files by itself, ie look at photos and if a tree
is in it tag the photo with tree (and even then perhaps not), relying on
humans to tag files is flawed - what would no hits mean - the infomation
doesn't exist or the file isn't tagged properly. It would be interesting to
see what librarians say about finding infomation. And think of possibilities
if Intel added small neural network CPU to their chips so recognising a tree
and an individual grandkid may be possible in hardware. Build it and they
will come.
-

A couple of things to bear in mind, which may or may not be relevant:

- By default the whole drive is not indexed, only the c:\users portion. So
unless you've changed the options {you can look in the Indexing Options
cpl} this is actually going to be doing a non-indexed search. Which
explains {somewhat} why it would be slower.

- Glad you got content: working.

- Generally you just type to make a search happen, there isn't a button to
start searching. As soon as you press a key we start searching so you
don't have to type the whole of a word you are looking for. The exception
to this is when you have the advanced search checked in which case there
is a Search button. But note that the search button converts your advanced
search options to a query string and puts it in the main search box, which
triggers a search.

- Yes, there isn't a search history unfortunately.

- Clicking the red 'X' should stop a search - if that doesn't work let me
know.

- As far as I can tell *.* works the same as * in filename searches. The
wildcards * and ? do work on other properties also. My co-worker Jonas has
a couple of blog entries which explain some of this:
http://blogs.msdn.com/jonasbar/default.aspx

Dave

To give you an idea I'm searching Drive C with non indexed, hidden etc
looking for a dll with Name = AQS (via field in advanced search) in the
name - name:*aqs* - the search is still going minutes later. Cmd searched
the disk in 1 or 2 seconds, using

dir c:\*aqs*.* /a /s

[and did I say, after making a cup of coffee that search is still
searching - it's when the progress bar starts overwriting the stop button
that is slow.]

There must be some problem - this looking for AQS in a file name is now
over 15 minutes of disk churning. Am I in fact searching for AQS anywhere
in a filename (not ext or path) where AQS may start, be in the middle, or
at the end of the name (or the only string in the name). I have (I
haven't counted for years) over 50,000 documents.

I must have been using contents keyword -content did find both names and
strings of digits (which humans call numbers).

Another 6 minutes go by since my last writing about speed while prograss
bar crawls across the stop button. It only took a minute or so to reach
the stop button (it's 1/2 way across the stop button).

Also there is no go button on Search Field. How does a mouse user
initiate a search?
Why does it delete my search terms when I hit the stop? Where is
autocomplete? Where is a Search History.

Have you noticed since IE4 was released MS has insisted we type rather
than use mouses. I will cut and paste.

Another 5 minutes go by, search seems no closer to finishing. Can't wait
for this to finish.

Yes, "content:" is missing from that doc unfortunately. I believe
there's a more complete MSDN doc in the works but it is not available
yet.

The behavior is that by default a search term on its own searches all
properties, including file contents. If you specifically want to search
only file names you can use the "filename:" keyword. If you specifically
want to search only contents you can use the "content:" keyword.

If you change the search options to say "Always search filenames only"
then a search term on its own only searches filenames. If you need to
search contents also, you can use the "content:" keyword {indexed
locations only}.

Is this the behavior you are seeing? If not let us know.

Dave

<.> wrote in message I tried @content as well as content:

If I bother constructing a search it's because I need to be precise to
avoid massive number of false hits. Not specifing any field wll find
contents but using either Indexing Server syntax or AQS and specifing
the contents it is not found.

In XP one entered advanced searching syntax in the containing text
field. But it would only parse it if indexing was on else it searched
for the characters. How do the Search Options affect searching.


Hmmmmmm The syntax "contents:search_term" is not even listed in the
syntax page you specified below.

So having said that...is that listing you link to an abridged version?

If yes - then where is the full listing please?

Otherwise its like trying to repair a car using pliers and a couple of
spanners......

Can do some things but not enough to complete the job!

Cheers

FG


Well just typing text into the seach field searches the contents of
items in indexed locations. But if you specifically want to search
the contents but not filename, subject etc. you can use
contents:search_term.

<.> wrote in message While you are on a roll would you like to find a correct query
language reference and post that.

If we are to believe the desktop search syntax (my point being is
that it lies) it is not possible to search for contents (2.6 or 3).
Yet Index Server does have a Content= field (which if I recall
correctly has servere limitations), Yet Indexing Server docs have
disappeared from the Vista PSDK.

Oh, and while I'm on a roll:

The latest query syntax doc is here:

http://www.microsoft.com/windows/desktopsearch/addresources/advanced3.mspx

The one someone else posted was for Windwso Search 2.6, which will
be very similar but not absolutely identical.

Also you discussed index size relative to documents size. There's
no way to estimate this exactly, because different files contribute
different amounts to the index size {e.g. pictures less, text docs
more}. But we typically see a range from less than 5% up to maybe
15%.

Dave

- We put a lot of effort into 'backing-off' the indexing so it
doesn't interfere with the user's normal use of the machine. So in
general this shouldn't be an issue.

- You can move the location of the index files to a different
location using the Indexing Options Control Panel.

Dave


To answer you questions briefly:

- The Windows Search indexer should be able to handle these kinds
of
scenarios. If you decide you don't want it to run you need to
disable the
Windows Search service.

- You can control what locations are indexed through the Indexing
Options
Control Panel, or programatically. We don't currently support
multiple
indexes.

OK, that's at least something because there are many locations on
my
harddisk which I wouldn't want to be indexed. If it actually
indexed
everything from the first to the last partition, it would be very
inefficient.

I think there's some control of when indexing happens
programatically, it depends exactly what scenario you are trying
to achieve.

My concern is that re-indexing would slow down my computer
considerably, so I would want Windows to perform indexing only
when
the computer is idle. I understand that this could mean that I
may
have an obsolete index for some time.

- Yes we support a pretty rich query syntax, an overview of which
is here:
http://windowshelp.microsoft.com/Windows/en-US/Help/73106209-6df0-432a-8cb7-df5d8ce02ec61033.mspx

Very good.

I hope this helps,

Yes, it does. Thanks.

Regarding the question about whether I can set where to place the
index files: I conclude that it cannot be done, i.e. the index
files
are mandatorily placed on partition C: where Windows Vista is
installed. Is that correct?

Actually, I would prefer to have the index files placed on a
different
partition but I suppose this can't be done.

Are there any estimates on how much harddisk space I should
reserve
for x GB of documents to be indexed (like 10 % for example, which
would mean I need 1 GB of extra space for every 10 GB of document
data)?
I understand that this depends on the type of data but as I
mentioned
before the data locations that I would like to be indexed consist
almost exclusively of PDF documents, Word, Excel, and Powerpoint
files.

Peter


Hi,

I have a couple of questions about the new index-based
full-text
search of Windows Vista.

1) Is it powerful enough to handle huge amounts of data
consisting of
PDF documents, Word, Excel and Powerpoint files (around 20 GB)?
Or
would a third-party solution like dtSearch be the better
choice? If
this is the better choice, can the indexing by Windows Vista be
disabled?

2) Is there any way I can manage or control the indexing
process?
a) Can I set the location of the index files?
b) Can I create multiple indexes?
c) Can I control in any way when the indexing takes place?

3) Can I perform advanced searches using Boolean operators?

Peter

 

[Guest]

- Clicking the red 'X' should stop a search - if that doesn't work let me
know.

It does stop but also deletes the term. Churning hard disks are annoying. I
want it to stop to see if the first hits are useful and if not to restart
the search.

Deleting anything I type makes me very angry.

A couple of things to bear in mind, which may or may not be relevant:

- By default the whole drive is not indexed, only the c:\users portion. So
unless you've changed the options {you can look in the Indexing Options
cpl} this is actually going to be doing a non-indexed search. Which
explains {somewhat} why it would be slower.

- Glad you got content: working.

- Generally you just type to make a search happen, there isn't a button to
start searching. As soon as you press a key we start searching so you
don't have to type the whole of a word you are looking for. The exception
to this is when you have the advanced search checked in which case there
is a Search button. But note that the search button converts your advanced
search options to a query string and puts it in the main search box, which
triggers a search.

- Yes, there isn't a search history unfortunately.

- Clicking the red 'X' should stop a search - if that doesn't work let me
know.

- As far as I can tell *.* works the same as * in filename searches. The
wildcards * and ? do work on other properties also. My co-worker Jonas has
a couple of blog entries which explain some of this:
http://blogs.msdn.com/jonasbar/default.aspx

Dave

To give you an idea I'm searching Drive C with non indexed, hidden etc
looking for a dll with Name = AQS (via field in advanced search) in the
name - name:*aqs* - the search is still going minutes later. Cmd searched
the disk in 1 or 2 seconds, using

dir c:\*aqs*.* /a /s

[and did I say, after making a cup of coffee that search is still
searching - it's when the progress bar starts overwriting the stop button
that is slow.]

There must be some problem - this looking for AQS in a file name is now
over 15 minutes of disk churning. Am I in fact searching for AQS anywhere
in a filename (not ext or path) where AQS may start, be in the middle, or
at the end of the name (or the only string in the name). I have (I
haven't counted for years) over 50,000 documents.

I must have been using contents keyword -content did find both names and
strings of digits (which humans call numbers).

Another 6 minutes go by since my last writing about speed while prograss
bar crawls across the stop button. It only took a minute or so to reach
the stop button (it's 1/2 way across the stop button).

Also there is no go button on Search Field. How does a mouse user
initiate a search?
Why does it delete my search terms when I hit the stop? Where is
autocomplete? Where is a Search History.

Have you noticed since IE4 was released MS has insisted we type rather
than use mouses. I will cut and paste.

Another 5 minutes go by, search seems no closer to finishing. Can't wait
for this to finish.

Yes, "content:" is missing from that doc unfortunately. I believe
there's a more complete MSDN doc in the works but it is not available
yet.

The behavior is that by default a search term on its own searches all
properties, including file contents. If you specifically want to search
only file names you can use the "filename:" keyword. If you specifically
want to search only contents you can use the "content:" keyword.

If you change the search options to say "Always search filenames only"
then a search term on its own only searches filenames. If you need to
search contents also, you can use the "content:" keyword {indexed
locations only}.

Is this the behavior you are seeing? If not let us know.

Dave

<.> wrote in message I tried @content as well as content:

If I bother constructing a search it's because I need to be precise to
avoid massive number of false hits. Not specifing any field wll find
contents but using either Indexing Server syntax or AQS and specifing
the contents it is not found.

In XP one entered advanced searching syntax in the containing text
field. But it would only parse it if indexing was on else it searched
for the characters. How do the Search Options affect searching.


Hmmmmmm The syntax "contents:search_term" is not even listed in the
syntax page you specified below.

So having said that...is that listing you link to an abridged version?

If yes - then where is the full listing please?

Otherwise its like trying to repair a car using pliers and a couple of
spanners......

Can do some things but not enough to complete the job!

Cheers

FG


Well just typing text into the seach field searches the contents of
items in indexed locations. But if you specifically want to search
the contents but not filename, subject etc. you can use
contents:search_term.

<.> wrote in message While you are on a roll would you like to find a correct query
language reference and post that.

If we are to believe the desktop search syntax (my point being is
that it lies) it is not possible to search for contents (2.6 or 3).
Yet Index Server does have a Content= field (which if I recall
correctly has servere limitations), Yet Indexing Server docs have
disappeared from the Vista PSDK.

Oh, and while I'm on a roll:

The latest query syntax doc is here:

http://www.microsoft.com/windows/desktopsearch/addresources/advanced3.mspx

The one someone else posted was for Windwso Search 2.6, which will
be very similar but not absolutely identical.

Also you discussed index size relative to documents size. There's
no way to estimate this exactly, because different files contribute
different amounts to the index size {e.g. pictures less, text docs
more}. But we typically see a range from less than 5% up to maybe
15%.

Dave

- We put a lot of effort into 'backing-off' the indexing so it
doesn't interfere with the user's normal use of the machine. So in
general this shouldn't be an issue.

- You can move the location of the index files to a different
location using the Indexing Options Control Panel.

Dave


To answer you questions briefly:

- The Windows Search indexer should be able to handle these kinds
of
scenarios. If you decide you don't want it to run you need to
disable the
Windows Search service.

- You can control what locations are indexed through the Indexing
Options
Control Panel, or programatically. We don't currently support
multiple
indexes.

OK, that's at least something because there are many locations on
my
harddisk which I wouldn't want to be indexed. If it actually
indexed
everything from the first to the last partition, it would be very
inefficient.

I think there's some control of when indexing happens
programatically, it depends exactly what scenario you are trying
to achieve.

My concern is that re-indexing would slow down my computer
considerably, so I would want Windows to perform indexing only
when
the computer is idle. I understand that this could mean that I
may
have an obsolete index for some time.

- Yes we support a pretty rich query syntax, an overview of which
is here:
http://windowshelp.microsoft.com/Windows/en-US/Help/73106209-6df0-432a-8cb7-df5d8ce02ec61033.mspx

Very good.

I hope this helps,

Yes, it does. Thanks.

Regarding the question about whether I can set where to place the
index files: I conclude that it cannot be done, i.e. the index
files
are mandatorily placed on partition C: where Windows Vista is
installed. Is that correct?

Actually, I would prefer to have the index files placed on a
different
partition but I suppose this can't be done.

Are there any estimates on how much harddisk space I should
reserve
for x GB of documents to be indexed (like 10 % for example, which
would mean I need 1 GB of extra space for every 10 GB of document
data)?
I understand that this depends on the type of data but as I
mentioned
before the data locations that I would like to be indexed consist
almost exclusively of PDF documents, Word, Excel, and Powerpoint
files.

Peter


Hi,

I have a couple of questions about the new index-based
full-text
search of Windows Vista.

1) Is it powerful enough to handle huge amounts of data
consisting of
PDF documents, Word, Excel and Powerpoint files (around 20 GB)?
Or
would a third-party solution like dtSearch be the better
choice? If
this is the better choice, can the indexing by Windows Vista be
disabled?

2) Is there any way I can manage or control the indexing
process?
a) Can I set the location of the index files?
b) Can I create multiple indexes?
c) Can I control in any way when the indexing takes place?

3) Can I perform advanced searches using Boolean operators?

Peter

 

[Guest]

The first thing I did when I got my new laptop was index the "my files"
folder so that it could search the contents of wordperfect files. This would
be such a great improvement since this isn't possible with my desktop
computer on XP (even Google Desktop has never been able to find anywhere near
all the documents containing words I am looking for).
UNFORTUNATELY it would seem that certain wordperfect files that I edit
during the day get REMOVED from Vista's searching engine. When I do a search
of "My Files" after a hard day's work, only about half the files I have
modified appear in the search window (annoying since I always back up my
day's work on the thumbdrive). Likewise, if I search for words contained in
documents (even file names!), Vista WILL NOT SEARCH about half the documents
I have modified. The ONLY thing I can figure is that, while Vista is
updating the index in the background, it blocks anything that I happen to
have open in Wordperfect at the time. This is my theory, since the files
that get blocked tend to be ones I have had open for longer durations of
time. Does anyone have a recommendation? Is it possible, say, to TELL Vista
when to update its index, so that it would incorporate the new material after
I've closed Wordperfect? Or could something else be afoot?

 

[cquirke (MVP Windows shell/user)]

On Mon, 12 Mar 2007 11:15:24 -0700, "Dave Wood [MS]"

Yes, "content:" is missing from that doc unfortunately. I believe there's a
more complete MSDN doc in the works but it is not available yet.

The behavior is that by default a search term on its own searches all
properties, including file contents. If you specifically want to search only
file names you can use the "filename:" keyword. If you specifically want to
search only contents you can use the "content:" keyword.

What a mess... I don't have Vista's search in front of me, but if
there are separate fields for name and "containing text..." then I'd
expect the "name" field to search the file name.

So far it's worked for what I've searched for, but it seems as if
searches like this...

*.exe, *.pif, *.dll, *.scr, *.com, *.cpl, *.cmd, *.bat

....or as worked in Win9x...

*.exe *.pif *.dll *.scr *.com *.cpl *.cmd *.bat

....don't seem to work either. I want to apply a policy that no code
files (infectable) are to be permitted in the data set that is to be
backed up, and that search is one way to check this.

If you change the search options to say "Always search filenames only" then
a search term on its own only searches filenames. If you need to search
contents also, you can use the "content:" keyword {indexed locations only}.

Ew... this is looking a bit too messy; if I want to learn a new search
syntax, I'd want Boolean operators as well. Maybe Agent Ransack would
be a good addition to my Vista builds :-/

It's a serious matter if a search appears to confirm something is not
present, when it really is. In that sense, Search hasn't been safe in
consumer OSs since WinME, given the hoops one has to go through EACH
TIME to get it to show *everything*, "system" or "hidden" or no.

Malware wants to hide, and I want to find it.

I expect the OS to be on my side, in that battle ;-)

No matter how beautiful (and Vista's search looks good, as if a lot of
effort had gone into it), a search is useless if I can't trust it.

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[cquirke (MVP Windows shell/user)]

In message <[email protected]> "Dave Wood [MS]"

- As far as I can tell *.* works the same as * in filename searches.

It should be similar, since the * wildcard matches on "." as well.
However, *.* wouldn't match a file without an extension.

That's good, and in keeping with how Odi's LFN Tools work.

Means you can use *. to find blank file name extensions (a quick tho
leaky way to favor folders over files) and *.* to find only files with
non-blank extensions (or literally, in a post-8.3-world, names that
have at least one . character in them)

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Dave Wood [MS]]

- Like most search engines, listing terms with spaces between gives items
that match ALL of the terms. So you would need to separate with OR because
you want files that match ANY of the terms:
*.exe OR *.pif OR *.dll etc...

I think that maybe explains a lot of what you are seeing below:
- name: searches filenames
- content: searches contents
- by default both filenames and contents are searched
- boolean operators AND OR NOT are supported {default is AND}


Dave

On Mon, 12 Mar 2007 11:15:24 -0700, "Dave Wood [MS]"

Yes, "content:" is missing from that doc unfortunately. I believe there's
a
more complete MSDN doc in the works but it is not available yet.

The behavior is that by default a search term on its own searches all
properties, including file contents. If you specifically want to search
only
file names you can use the "filename:" keyword. If you specifically want
to
search only contents you can use the "content:" keyword.

What a mess... I don't have Vista's search in front of me, but if
there are separate fields for name and "containing text..." then I'd
expect the "name" field to search the file name.

So far it's worked for what I've searched for, but it seems as if
searches like this...

*.exe, *.pif, *.dll, *.scr, *.com, *.cpl, *.cmd, *.bat

...or as worked in Win9x...

*.exe *.pif *.dll *.scr *.com *.cpl *.cmd *.bat

...don't seem to work either. I want to apply a policy that no code
files (infectable) are to be permitted in the data set that is to be
backed up, and that search is one way to check this.

If you change the search options to say "Always search filenames only"
then
a search term on its own only searches filenames. If you need to search
contents also, you can use the "content:" keyword {indexed locations
only}.

Ew... this is looking a bit too messy; if I want to learn a new search
syntax, I'd want Boolean operators as well. Maybe Agent Ransack would
be a good addition to my Vista builds :-/

It's a serious matter if a search appears to confirm something is not
present, when it really is. In that sense, Search hasn't been safe in
consumer OSs since WinME, given the hoops one has to go through EACH
TIME to get it to show *everything*, "system" or "hidden" or no.

Malware wants to hide, and I want to find it.

I expect the OS to be on my side, in that battle ;-)

No matter how beautiful (and Vista's search looks good, as if a lot of
effort had gone into it), a search is useless if I can't trust it.

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

--------------- ---- --- -- - - - -

 

[cquirke (MVP Windows shell/user)]

On Thu, 22 Mar 2007 19:16:29 -0700, "Dave Wood [MS]"

- Like most search engines, listing terms with spaces between gives items
that match ALL of the terms. So you would need to separate with OR because
you want files that match ANY of the terms:
*.exe OR *.pif OR *.dll etc...

I think that maybe explains a lot of what you are seeing below:
- name: searches filenames
- content: searches contents
- by default both filenames and contents are searched
- boolean operators AND OR NOT are supported {default is AND}

What gets me, is how these behaviors shift around.

In Win9x, if you don't enclose in quotes, then spaces act as
delimeters, and separate items are OR'd, not AND'd. This is in
keeping with general command line filespec rules.

So...

Exit to DOS.pif

....finds anything with *Exit*, *to*, or *DOS.pif*, while...

"Exit to DOS.pif"

....finds "Exit to DOS.pif".

So, also...

*.EXE *.COM *.SCR *.CMD *.BAT *.PIF *.CPL

....finds any files that are designed to run raw code when "opened".


In XP, this changed; to do the same thing in XP< I have to do this...

*.EXE, *.COM, *.SCR, *.CMD, *.BAT, *.PIF, *.CPL

....as well as dig into Advanced, else any PoS that wants to hide from
my search can do so by setting System, Hidden etc. attributes.


In Vista, even the above doesn't work. If I want to make sure there
are no code files sneaking into my data set, I have to search for each
of those items, one at a time. MS hasn't anticipated this need, so
there's no "show me all code files" option.


It's as important to know that something does NOT exist, and be able
to trust that result, as it is to find things.

If search can't be trusted, it's not worth using - and it is certainly
not worth bogging down the system with indexing overhead if the result
is a "search" that effectively lies about what is where.

-------------------- ----- ---- --- -- - - - -

Tip Of The Day:
To disable the 'Tip of the Day' feature...