Welcome to Vista Banter. You are currently viewing our boards as a guest which gives you limited access to view most discussions, articles and access our other FREE features. By joining our free community you will have access to ask questions and reply to others posts, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today! If you have any problems with the registration process or your account login, please contact contact support. |
|
Windows Vista File Management Issues or questions in relation to Vista's file management. (microsoft.public.windows.vista.file_management) |
|
LinkBack | Thread Tools | Display Modes |
|
|||
Is Windows Vista index-based full-text search powerful enough?
And where have Search Document Summaries gone from 2000/XP? That one could
access via Computer Management - Services and Application - Indexing Server and there was Query forms under this. "Dave Wood [MS]" wrote in message ... 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. "Flash Gortdon" wrote in message ... 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 ... 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. "Dave Wood [MS]" wrote in message ... Oh, and while I'm on a roll: The latest query syntax doc is he 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 ... - 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 ... "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 he 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@4 ax.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 |
|
|||
Is Windows Vista index-based full-text search powerful enough?
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 ... 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 ... 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. "Flash Gortdon" wrote in message ... 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 ... 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. "Dave Wood [MS]" wrote in message ... Oh, and while I'm on a roll: The latest query syntax doc is he 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 ... - 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 ... "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 he 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 |
|
|||
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. |
|
|||
Is Windows Vista index-based full-text search powerful enough?
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 ... 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 ... 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 ... 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. "Flash Gortdon" wrote in message ... 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 ... 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. "Dave Wood [MS]" wrote in message ... Oh, and while I'm on a roll: The latest query syntax doc is he 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 ... - 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 ... "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 he 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 |
|
|||
Is Windows Vista index-based full-text search powerful enough?
- 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 ... 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 ... 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 ... 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. "Flash Gortdon" wrote in message ... 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 ... 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. "Dave Wood [MS]" wrote in message ... Oh, and while I'm on a roll: The latest query syntax doc is he 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 ... - 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 ... "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 he 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 |
|
|||
Indexing Problems with Wordperfect Files
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? |
|
|||
Is Windows Vista index-based full-text search powerful enough?
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! --------------- ---- --- -- - - - - |
|
|||
Is Windows Vista index-based full-text search powerful enough?
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! --------------- ---- --- -- - - - - |
|
|||
Is Windows Vista index-based full-text search powerful enough?
- 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 ... 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! --------------- ---- --- -- - - - - |
|
|||
Is Windows Vista index-based full-text search powerful enough?
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... -------------------- ----- ---- --- -- - - - - |