"Monitor Changes" priority for fresh index

[cube]

After installing 1.5.0.1400a x64 (portable/'fresh') onto a Win11 machine, I'd added my standard indexing locations (in my case, all network drives), and opened the verbose debug console, mostly for curiosity.

I immediately noticed that the indexing process seemed unusually slow, then I realised that the slowdowns appeared to be caused by a copy I was performing elsewhere over the local network, i.e., the indexing was slowed significantly due to changes being detected (I had enabled 'detect changes' for all of my drives). As expected, disabling detection for the drive in question instantly fixed the issue. I noticed this again when I forgot about it and copied files to a DIFFERENT network drive.

Would it be a better idea to handle the 'change detection' once a drive has been indexed already? I should probably note that in my cases above, any change detected was NOT on the drive that was currently being indexed [and in that case I could see a benefit to indexing changes if/when detected]

[void]

Would it be a better idea to handle the 'change detection' once a drive has been indexed already?

Changes made while indexing would be missed.

What is the network drive hardware/OS?
-Everything uses ReadDirectoryChangesW API to monitor folders, this shouldn't be causing any slowness.
Everything also uses SHChangeNotify to monitor changes. It's possible this is causing trouble with repeated UPDATEDIR events.

Is the copying done to a folder that has many items?

Try disabling SHChangeNotify and see if the issue persists:

• 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:
  change notify
• Select: sh_change_notify
• Set the value to: false
• Click OK.