Copy to (slow) USB drive may stall when Everything service is running

[vinix]

I copy lots of files (50~200GB) to usb drives using Robocopy frequently. These are slow (fluctuating between 1~112MB/s) 128 or 256GB flash drives. I found that the copy process stalled regularly and I have to force shutdown the PC and reboot or OS would stopped responding gradually. Finally I found that after I stopped Everything service before copy, the problem is gone. I tried updating Everything to 1400a from 1396a, but it didn't solve the problem.

This problem started to occur in recent months, and occurred more often on slow drives. The same process usually succeeded on 512GB USB SSDs when Everything service is running. There is no related event in Event Viewer, so I'm not sure what happened accuately.

PC: ASUS D700MA
OS: Windows 11 25H2 26200.7171
Everything version: 1.5 Aplha 1400a

[void]

Could you please send some debug information:

• --Wait for your USB drive to stall.
• In Everything 1.5, from the Tools menu, Under the Debug submenu, click Start Debug Logging.
  --Wait for 1 minute while Everything captures events.
• In Everything 1.5, from the Tools menu, Under the Debug submenu, click Stop Debug Logging.
  --This will open your %TEMP%\Everything Debug Log.txt in Notepad.
• Please upload this file in a bug report.

Are you indexing properties or content?

[vinix]

Sorry for the delay.

I can not get debug information because when USB drive stalled, Everything (1.5.0.1405a) icon in the taskbar stalled as well so I can't open Everything window.

I didn't indexing properties or content.

[void]

Windows doesn't share access to USB drives.
If something is reading/writing to the USB drive, Everything will hang.

Please try setting Everything to update with low IO priority:
Copy and paste the following into your Everything search box:
/folder_update_thread_mode_background=1
Press ENTER in your Everything search box.
If successful, folder_update_thread_mode_background=1 is shown in the status bar for a few seconds.

Copy and paste the following into your Everything search box:
/monitor_thread_mode_background=1
Press ENTER in your Everything search box.
If successful, monitor_thread_mode_background=1 is shown in the status bar for a few seconds.

Please try removing the USB drives from your Everything index:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Uncheck Automatically index new fixed volumes.
• Uncheck Automatically index new removable volumes.
• For each USB NTFS volume:
  • Uncheck Include in database.
• Click the FAT tab on the left. (Everything 1.5 or later)
• Uncheck Automatically index new fixed volumes.
• Uncheck Automatically index new removable volumes.
• For each USB FAT volume:
  • Uncheck Include in database.
• Click the Folders tab on the left.
• Remove any USB volumes:
• Click OK.

Does the issue persist?

[therube]

Aside from the actual issue, if you were to Index | Pause, before starting ROBOCOPY (& then Index | Update, after ROBO finished) would that bypass the issue?

If something is reading/writing to the USB drive, Everything will hang.

You say "hang", but do you really mean "busy", (so essentially a hang) until the USB becomes free?

[void]

You say "hang", but do you really mean "busy", (so essentially a hang) until the USB becomes free?

Everything will hang if Everything tries to access the USB drive while there is a lot of IO from another application.
Everything will recover when the there's no IO to the USB device.

[vinix]

I've noticed that this problem only occurs when copying files to 256GB drives, though it’s inconsistent. Today, while copying files from my internal SSD to two 256GB drives simultaneously, the process to the second drive hung.

During this, I was able to open Everything, and set /folder_update_thread_mode_background=1 and /monitor_thread_mode_background=1 via the search bar. However, when I navigated to Options > Indexes > FAT, the options window, main window and taskbar icon froze, and I can not close them via Task Manager. Resource Monitor showed zero I/O activity for the second drive.

In Event Viewer > System, I found one event reporting bad blocks on the second drive, and four events reporting controller errors on the first drive (even though the copy process to the first drive continued).

Interestingly, I recall that if I exit Everything before starting the copy, the process completes without any issues. I'll try the remaining steps to see if the situation improves. I've excluded these drives in Options > Indexes > FAT and paused Indexing, but it didn't work. I rebooted the PC and close Everything icon and service then will retry the process.

[therube]

Event Viewer > System, I found one event reporting bad blocks on the second drive, and four events reporting controller errors on the first drive

My thought. Flunky drive(s).

(even though the copy process to the first drive continued)
...
I recall that if I exit Everything before starting the copy, the process completes without any issues.

That a copy finishes, does not mean it was successful.
Verify (by hash or content compare) that source & targets ends are in fact identical.

Likewise verify that other copies, by other means (Windows Explorer or whatever) are also in fact, identical.


(Got one here, it says, "Team 128GB", & it simply is not reliable. One time you're OK, & literally a moment later & you've got corrupt files. And that's not to mention inconsistency in the copy process itself.)