If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
"Modifying index location is disabled by a policy."
I am one of those strange sorts of people who find Windows Search useful. I think Windows periodically decides to rebuild the index. I've caught it in the act a time or two and it was nothing I had done. What I have done sometimes is to change the location where the index is stored. I tried to do this tonight and received the subject message. I don't think this is because of anything I did. I'd change the policy if I could find it... (Win 10 Pro). Did an update cause this? |
Ads |
#2
|
|||
|
|||
"Modifying index location is disabled by a policy."
On 2018-04-06 22:24, Jason wrote:
I am one of those strange sorts of people who find Windows Search useful. I think Windows periodically decides to rebuild the index. I've caught it in the act a time or two and it was nothing I had done. What I have done sometimes is to change the location where the index is stored. I tried to do this tonight and received the subject message. I don't think this is because of anything I did. I'd change the policy if I could find it... (Win 10 Pro). Did an update cause this? Maybe here? - HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search!PreventModifyingIndexedLocations Using that Excel sheet I downloaded 5 minutes ago; check this out: https://www.microsoft.com/en-us/down....aspx?id=25250 Regards, -- ! _\|/_ Sylvain / ! (o o) Memberavid-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society oO-( )-Oo Where do forest rangers go to get away from it all? |
#3
|
|||
|
|||
"Modifying index location is disabled by a policy."
|
#4
|
|||
|
|||
"Modifying index location is disabled by a policy."
On Fri, 6 Apr 2018 22:24:51 -0400, Jason wrote:
I am one of those strange sorts of people who find Windows Search useful. Useful? Yes. Any good as compared to alternatives like Search Everything? No. |
#5
|
|||
|
|||
"Modifying index location is disabled by a policy."
|
#7
|
|||
|
|||
"Modifying index location is disabled by a policy."
On Sat, 7 Apr 2018 16:56:26 -0400, Jason
wrote: In article , says... On Fri, 6 Apr 2018 22:24:51 -0400, Jason wrote: I am one of those strange sorts of people who find Windows Search useful. Useful? Yes. Any good as compared to alternatives like Search Everything? No. I use Everything a lot. Unless you turn it loose to actually read the files and index them I don't find it useful for content searches, but it's great when you cannot quite remember the name of the file that you are certain you created yesterda.... Windows search does index content for times when that is what you need. For content searches, many of us use Agent Ransack. Other than to satisfy my curiosity now and then, (to remind myself that it's still crap), I haven't used Windows Search since the beginning of the XP days, back when I didn't know any better. |
#8
|
|||
|
|||
"Modifying index location is disabled by a policy."
|
#9
|
|||
|
|||
"Modifying index location is disabled by a policy."
On Sun, 8 Apr 2018 11:03:26 -0400, Jason wrote:
In article , says... I haven't used Windows Search since the beginning of the XP days, back when I didn't know any better. I don't know how/if it's changed since XP days - that was a long time ago. It becomes more useful if you spend the time to customize it, i.e., changing default locations where it searches and fiddling with filetypes that do or do not get indexed. Are there important differences between Agent Ransack and Everything when used in indexing mode? I use Everything for filename searches because the results are provided instantaneously. I use Agent Ransack for content searches, or other specialized searches. Like I mentioned earlier, I do try Windows Search every now and then to make sure it's still awful. It is. :-) I'm not interested in customizing it or messing around with its index options. There are much better choices available. |
#10
|
|||
|
|||
"Modifying index location is disabled by a policy."
|
#11
|
|||
|
|||
"Modifying index location is disabled by a policy."
Jason wrote:
In article , lid says... There are much better choices available. I'm willing to change to something better :-) My understanding is that Everything monitors the MFT so its searches are always up to date. Does Agent Ransack indexing do that too or does one have to goose it to update the index? The USN is a change journal available on NTFS. But not on FAT32. Everything.exe could listen to that journal, to keep the file list it keeps up to date. Everything.exe doesn't index content or look inside files that I know of. Agent Ransack is the free version of Mythic Software search. It does both filename search as well as content search, but with no preparation in advance. If it takes 2 hours to read the hard drive from end to end, then a search scope involving the entire drive and all of its contents, will also take 2 hours. It doesn't make an index in advance. I can't find one. Mythic Software FileLocator Pro ($$), keeps an Inverted Index. But, the Index is "on demand", with the company recommending the usage of Task Scheduler to kick off daily indexes. They don't seem to tie into the USN Journal. A trial version is available. https://help.mythicsoft.com/fileloca...-interface.htm Windows Search Indexer listens to the USN Journal, and indexes (or removes entries) according to what happens. It's not clear how Windows Search Indexer handles FAT32 partitions. (You could hook into ETW events, but that might be costly.] ******* Everything.exe is fast on its first file listing run, because it attempts to read the $MFT directly. However, all the $MFT gives you for your trouble, is the filename. There is other metadata that Everything also wants to include in the file list. This changes a 2 second operation into a 15 second operation. This is one of the inevitable tradeoffs - if you want to make the interface look like what everyone else offers, you pay a price for the resources. Filling in file sizes on the fly (when the search happens), would be clunky. https://www.voidtools.com/support/everything/options/ "Everything service Install the Everything service. The Everything service will allow the Everything search window to read and monitor the USN Journal on all NTFS volumes. " "To include extra file information in the Everything index: *In "Everything", from the Tools menu, click Options *Click the Indexes tab. *Check the desired options: *Index file size *Index folder size *Index date created *Index date modified *Index date accessed *Index attributes [Adjusting those options might reduce scan/rescan time.] " For all these tools, FAT32 is an outlier, as it doesn't have a change journal, and it requires some other mechanism to trigger a rescan. A scan/index once a day, isn't going to be good for keeping track of downloads (which could be showing up during the day). Whereas with the USN journal, NTFS users have a possibility of keeping the state information up to date. Paul |
#12
|
|||
|
|||
"Modifying index location is disabled by a policy."
On Sun, 8 Apr 2018 22:21:57 -0400, Jason wrote:
In article , says... There are much better choices available. I'm willing to change to something better :-) My understanding is that Everything monitors the MFT so its searches are always up to date. "Always up to date" refers to NTFS volumes because they have a USN journal. FAT volumes and network shares periodically get scanned and an index gets built. When you attempt to do a search, the index is consulted. Either way, the results should appear instantaneously. Does Agent Ransack indexing do that too or does one have to goose it to update the index? Agent Ransack doesn't create an index. That approach has pros and cons. |
#13
|
|||
|
|||
"Modifying index location is disabled by a policy."
On Mon, 09 Apr 2018 00:31:14 -0400, Paul wrote:
Jason wrote: In article , lid says... There are much better choices available. I'm willing to change to something better :-) My understanding is that Everything monitors the MFT so its searches are always up to date. Does Agent Ransack indexing do that too or does one have to goose it to update the index? The USN is a change journal available on NTFS. But not on FAT32. Everything.exe could listen to that journal, to keep the file list it keeps up to date. Everything.exe doesn't index content or look inside files that I know of. Correct. Agent Ransack is the free version of Mythic Software search. It does both filename search as well as content search, but with no preparation in advance. If it takes 2 hours to read the hard drive from end to end, then a search scope involving the entire drive and all of its contents, will also take 2 hours. I realize that "2 hours" was just a figure of speech, but just now it took 1 minute 4 seconds to search my 38TB volume. Most people are probably searching a volume 1/10th that size, so I'd expect the results to arrive even faster for most people. It doesn't make an index in advance. I can't find one. Same as above. Still correct. Everything.exe is fast on its first file listing run, because it attempts to read the $MFT directly. However, all the $MFT gives you for your trouble, is the filename. There is other metadata that Everything also wants to include in the file list. This changes a 2 second operation into a 15 second operation. This is one of the inevitable tradeoffs - if you want to make the interface look like what everyone else offers, you pay a price for the resources. Filling in file sizes on the fly (when the search happens), would be clunky. You might be using an older version of Everything. There have been reports of older versions taking a number of seconds to produce search results. If you use a more recent version, you should see search results that are indistinguishable from instantaneous. Version 1.4.1.895 appears to be the most recent. http://www.voidtools.com/downloads/ Bottom line, if Everything is taking from 2 to 15 seconds to produce search results, something is very wrong. https://www.voidtools.com/support/everything/options/ "Everything service Install the Everything service. The Everything service will allow the Everything search window to read and monitor the USN Journal on all NTFS volumes. " "To include extra file information in the Everything index: *In "Everything", from the Tools menu, click Options *Click the Indexes tab. *Check the desired options: *Index file size *Index folder size *Index date created *Index date modified *Index date accessed *Index attributes [Adjusting those options might reduce scan/rescan time.] " Note that 'scan/rescan time' doesn't refer to search time. The scan or rescan is done out of band. Performing a search doesn't trigger a scan/rescan. |
#14
|
|||
|
|||
"Modifying index location is disabled by a policy."
Char Jackson wrote:
Note that 'scan/rescan time' doesn't refer to search time. The scan or rescan is done out of band. Performing a search doesn't trigger a scan/rescan. Everything.exe will prepare a file for you, listing all the files on a partition. If this is done using only information which it obtains from the $MFT, it finishes in a couple seconds. If it's expected to add file size and creation date to that, then the time increases to make the file list, because the folder tree must be traversed to collect the information. Preparing the database of all partitions, takes n*(time_for_single_partition). I haven't timed that, because I haven't bothered to actually install and use Everything.exe as intended (I have some FAT32 partitions here, and they would leave gaps in my coverage). I've been using it primarily for creating a text file listing a single partition. (I was testing this, in the hope that a $MFT approach would give a more complete file list than other methods.) I still don't think any method on Windows, gives a complete file list. There's always a few missing. This has nothing to do with the search time, since once the blah.db is prepared for all the partitions, all that Everything.exe has to do is consult that database. I haven't characterized that, because with really no solution covering my mixed NTFS/FAT32 here (the FAT32 from old disks), it's not worth wasting time on fancy setups. "Any old laborious search" is good enough on this machine, until the FAT32 problem can be solved. The setup on my other machine doesn't have this problem, as it's pure NTFS over there. But I don't stand in front of that machine all day - that machine isn't my surf machine. Paul |
#15
|
|||
|
|||
"Modifying index location is disabled by a policy."
On Mon, 09 Apr 2018 03:51:14 -0400, Paul wrote:
Char Jackson wrote: Note that 'scan/rescan time' doesn't refer to search time. The scan or rescan is done out of band. Performing a search doesn't trigger a scan/rescan. Everything.exe will prepare a file for you, listing all the files on a partition. Right, but that's one of its minor capabilities, somewhere way down the list. That's not what most people would do with Everything. If this is done using only information which it obtains from the $MFT, it finishes in a couple seconds. If it's expected to add file size and creation date to that, then the time increases to make the file list, because the folder tree must be traversed to collect the information. Irrelevant to getting search results, right? You wouldn't go to the trouble of creating a file list, then as a separate step, search that file list. That wouldn't make sense. Preparing the database of all partitions, takes n*(time_for_single_partition). I haven't timed that, because I haven't bothered to actually install and use Everything.exe as intended (I have some FAT32 partitions here, and they would leave gaps in my coverage). Why do you think your FAT32 partitions would leave gaps? This has nothing to do with the search time, since once the blah.db is prepared for all the partitions, all that Everything.exe has to do is consult that database. I haven't characterized that, because with really no solution covering my mixed NTFS/FAT32 here (the FAT32 from old disks), it's not worth wasting time on fancy setups. Everything works fine with a mix of NTFS and FAT32 volumes. That's also how I use it. "Any old laborious search" is good enough on this machine, until the FAT32 problem can be solved. I'm curious about your FAT32 problem. |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|