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

In message <> "Dave Wood [MS]"
<> wrote:

>- 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)
--
Insert something clever here.

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.
-
"Dave Wood [MS]" <> wrote in message
news:...
>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
>
> <.> wrote in message news:...
>> 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.
>>
>> "Dave Wood [MS]" <> wrote in message
>> news:...
>>> 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 news:...
>>>>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.
>>>>
>>>>
>>>> "Flash Gortdon" <> wrote in message
>>>> news:%...
>>>>> 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
>>>>>
>>>>>
>>>>> "Dave Wood [MS]" <> wrote in message
>>>>> news:...
>>>>>> 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 news:...
>>>>>>> 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.
>>>>>>>
>>>>>>> "Dave Wood [MS]" <> wrote in message
>>>>>>> news:...
>>>>>>>> Oh, and while I'm on a roll:
>>>>>>>>
>>>>>>>> The latest query syntax doc is here:
>>>>>>>>
>>>>>>>> http://www.microsoft.com/windows/des...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
>>>>>>>>
>>>>>>>> "Dave Wood [MS]" <> wrote in message
>>>>>>>> news:...
>>>>>>>>>- 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
>>>>>>>>>
>>>>>>>>> "Peter Frank" <> wrote in message
>>>>>>>>> news:...
>>>>>>>>>> "Dave Wood [MS]" <> wrote:
>>>>>>>>>>
>>>>>>>>>>>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/Win...02ec61033.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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>"Peter Frank" <> wrote in message
>>>>>>>>>>>news:artou2hcshf1cdqi4as50apfjr80400qus @4ax.com...
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

- 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.


"Dave Wood [MS]" <> wrote in message
news:...
>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
>
> <.> wrote in message news:...
>> 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.
>>
>> "Dave Wood [MS]" <> wrote in message
>> news:...
>>> 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 news:...
>>>>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.
>>>>
>>>>
>>>> "Flash Gortdon" <> wrote in message
>>>> news:%...
>>>>> 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
>>>>>
>>>>>
>>>>> "Dave Wood [MS]" <> wrote in message
>>>>> news:...
>>>>>> 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 news:...
>>>>>>> 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.
>>>>>>>
>>>>>>> "Dave Wood [MS]" <> wrote in message
>>>>>>> news:...
>>>>>>>> Oh, and while I'm on a roll:
>>>>>>>>
>>>>>>>> The latest query syntax doc is here:
>>>>>>>>
>>>>>>>> http://www.microsoft.com/windows/des...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
>>>>>>>>
>>>>>>>> "Dave Wood [MS]" <> wrote in message
>>>>>>>> news:...
>>>>>>>>>- 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
>>>>>>>>>
>>>>>>>>> "Peter Frank" <> wrote in message
>>>>>>>>> news:...
>>>>>>>>>> "Dave Wood [MS]" <> wrote:
>>>>>>>>>>
>>>>>>>>>>>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/Win...02ec61033.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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>"Peter Frank" <> wrote in message
>>>>>>>>>>>news:artou2hcshf1cdqi4as50apfjr80400qus @4ax.com...
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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?

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!
>--------------- ---- --- -- - - - -

On Tue, 13 Mar 2007 23:54:09 -0600, DevilsPGD
>In message <> "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!
>--------------- ---- --- -- - - - -

- 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


"cquirke (MVP Windows shell/user)" <> wrote in
message news:...
> 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!
>>--------------- ---- --- -- - - - -

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...
>-------------------- ----- ---- --- -- - - - -