1.4.x (latest beta) - offline drives detection

[Devil505]

I'm using a couple of external drives and TrueCrypt containers.
Everything doesn't seem to check if the drives/ containers are online at the time of the search as I get results from drives that are not available at that time.
That's even the case if everything isn't running in the background and a search query actually starts the program new.
Options - indexes - NTFS - Monitor changes is checked on the drives in question, and the options dialog correctly shows the drives as removable and seems to be aware of them being offline because the "enable USN journal" is greyed out.

Now while it might be intended to give access to the content of drives temporarily offline, an option to suppress offline files in the result list might be handy to say the least.
Furthermore if offline drives stay in the index a warning at some time would be nice, as that means if you use automatic inclusion without excluding the drives in question, the content of temporarily mounted crypted drives might show up in the index (not desired for privacy/ secrecy).

[void]

Offline volumes stay in the index until they are manually removed in Everything 1.4 (for the time being..)

An option to automatically remove offline volumes is on my TODO list.

To manually remove an offline volume from the Everything index:

• In "Everything", from the Tools menu, click Options.
• Click the NTFS tab.
• Select the offline NTFS volume.
• Click Remove.
• Click OK.

[Devil505]

Thanks for the quick clarification.
I wonder if it would be possible to implement a toggle that would simply exclude results from offline volumes from the search results without removing the offline volumes from the index.
I happen to have a dedicated PC that serves as "disk jockey" with a couple of external drives that will only be connected on demand.
With the current stable version, adding them is a pain, as re-indexing all the drives usually takes more than an hour because when they are connected the stable version doesn't update the indexes but rather re-scans ALL drives - I was hoping the beta version might save me a lot of time there.

[w64bit]

I think it's better to add v1.3 behavior as an option (to redo indexes every time a drive is offline/online).
Thank you

[CruNcher]

No no no better have left overs then to much IO access from rebuilding, hiding those files of a offline volume that would be at least a nice workaround for the time being

less reads/writes might be not so important for a Mechanical HDD though everything takes it's margin of inefficiency, it uses the pagefile it needs to read the mft then it's database access there is a lot of IO going on i mean in terms of operations not intensity and especially SSD users will be happy if only as much as needed IO is going on but also Mechanical drives gonna live longer and less IO saves energy as well

highest priority should be in my opinion improving IO behavior as much as possible (no unnecessary IO pooling only if absolutely needed) and trying to have no drawbacks from it

@void

Is the parsing speed of the database only dependent on the volume speed so putting the database or entire everything on a ramdrive (at kernel boot time) could improve overall loading times entirely and additionally lower IO and speedup sorting ?

Or would it allocate the database again into the System Memory anyways ?

i really would take that option into account for me disabling the whole serachindexer and freeing that ram for a at boot time persistent in memory everything database

Or wouldn't it be more efficient overall to integrate with the Windows Search directly Microsoft i guess also uses the MFT for Indexing https://msdn.microsoft.com/en-us/librar ... 85%29.aspx ?


Maybe overwriting the indexing itself by writing directly into the Windows Search Index Hijacking it's indexing slowness

Third-party developers can create applications that consume the data in the index through programmatic queries, and can extend the data in the index for custom file and item types to be indexed by Windows Search. If you want to show query results in Windows Explorer, you must implement a Shell data source before you can create a protocol handler to extend the index. However, if all queries are programmatic (through OLE DB for example) and interpreted by the application's code rather than the Shell, a Shell namespace is still preferred but not required.

[void]

Everything 1.4 will only re-index volumes that are out of date.

Adding a volume to the index will only access the volume being added.
There should be no disk IO when re-indexing after removing a volume from the index.

Everything stores its entire database in memory. Once loaded from memory at startup, Everything will never read this database from disk again.

Is the parsing speed of the database only dependent on the volume speed so putting the database or entire everything on a ramdrive (at kernel boot time) could improve overall loading times entirely and additionally lower IO and speedup sorting ?

The speed of the volume does affect Everythings loading performance.
The database is only loaded once from disk. If Everything needs to rebuild, it will re-use up to date indexes in memory. It will never reload from the Everything.db on disk.
The database is not saved to disk until you exit Everything.

There would be no benefit in loading the Everything.db from a ramdisk, since copying the Everything.db to the ramdisk would take the same time for Everything to load once directly from the disk. There would be a benefit to a ramdisk if you are running / exiting Everything multiple times.

There would be no improvement to sorting performance when using a ramdisk.