Understanding Indexing an encrypted drive.

[ChrisGreaves]

Encrypted.jpg

I am curious, is all. Each morning when I boot up I read the online news and by then Everything is alive and well, and I can locate documents on my data drive, T:, which is a Veracrypt encrypted partition of the only drive on the laptop.
This morning I was in a hurry and wanted to inspect a specific document before I read the news, so I fired up Everything 1.5b from my task bar. The search

t:\ ext:doc

had populated the results list instantly, but executing a DOCument did not open the document.
After about five seconds TaDa! the document(s) were available.

I suspect - but am not sure - that the 5-second delay was Everything 1.5b updating its indexes.

At the time I open Everything, the boot sequence has decrypted the partition so that a "drive T:" is visible in Explorer.

I am puzzled that the results list is populated with document names that I know exist but which are temporarily inaccessible.
Perhaps Everything 1.5b was so busy rebuilding/updating indexes that it could not recognize my double-click execution method?

From my point of view, Everything 1.5b is working Just Fine :clapping:, and it is only my normal use of the laptop (Everything before news) that is different. My impatience.
Thanks for any discussion, Chris
P.S. I suspect that I think of "offline" as being quite different from "encrypted". To me an offline tape was a reel of tape that was still in the cupboard.
Today my encrypted partition is online as soon as I Mount that partition with Veracrypt.
That same weird distinction with reel-to-reel tapes existed during the process of mounting: The operator slid the tape onto the hub; then the operator fed the leading end of the tape through the rollers; then wrapped the end of the tape around the take-up spool; then pressed the "LOAD" button to close the sliding door and then the drive would wind on some tape until it came to the reflective marker, then read the volume header, then ... That is, we had a lot of visible activities going on. Today we generally can't see that sequence of activities. C

[void]

I am puzzled that the results list is populated with document names that I know exist but which are temporarily inaccessible.
Perhaps Everything 1.5b was so busy rebuilding/updating indexes that it could not recognize my double-click execution method?

It doesn't sound like Everything was indexing and was already up-to-date.
Typically, executing a file is instant.
Windows/Veracrypt might be doing something in the background to bring the opened file into memory from disk.
The file would have to be decrypted before it is executed and 5 seconds seems reasonable.



The next time you see this, try pressing up/down in Everything.
Does Everything switch the selection immediately?
-If so, the file was executed, the process was created and it's the opened program that is just slow.
-If not, creating the new process is taking a long time. Could be decryption overhead or antivirus.



If Everything freezes for those 5 seconds then it's definitely an external issue.
Everything will wait for the executed item to start.
To execute items in a background thread and avoid this freeze in Everything:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  execute
• Select: shell_execute_thread
• Set the value to: true
• Click OK.

The new process may still take 5 seconds to start, but at least Everything will not freeze during this time.