Everything index not updated when files are moved via Git Bash (MSYS2) on Windows

[Serg2000Mr]

Hi,

I noticed that Everything's real-time index doesn't update when files are moved or renamed using Git Bash (MSYS2) on Windows.
(Claude Code uses it)

Steps to reproduce:

Open Everything, navigate to a folder
In Git Bash: mv file.txt subfolder/file.txt
Check Everything immediately — old path still shown, new path not indexed
Expected: Index updates in real time, as it does with Windows Explorer or PowerShell Move-Item.

Actual: Old path persists in the index. Everything only picks up the change after a manual reindex or after some delay.

Workaround: Using PowerShell Move-Item or cmd /c move instead of bash mv — index updates immediately.

Environment:

Everything 1.4.1.1032 (x64)
Windows 10 Pro 10.0.19045
Git Bash (MSYS2 / mingw64)
Question: Is this a known limitation? Is it related to how MSYS2 triggers (or doesn't trigger) NTFS change notifications? Any plans to address this in 1.5?

[void]

Thank you for the issue report Serg2000Mr,

The NTFS driver updates the USN Journal.

No changes should be missed.

There might be a short name issue or the wrong information logged to the USN Journal.

Could you please send some debug output when moving the file:

• In Everything, type in the following search and press ENTER:
  
  /verbose
• Type in the following search and press ENTER:
  
  /debug_log
• In Git Bash, run:
  mv file.txt subfolder/file.txt
• In Everything, type in the following search and press ENTER:
  
  /restart
• Could you please upload your %TEMP%\Everything Debug Log.txt in a bug report.

I was unable to reproduce the issue my end.
Are you sure it's an NTFS volume? and not a ReFS dev drive?
If its a ReFS dev drive, you'll need Everything 1.5.

[Serg2000Mr]

Hi void, thanks for the quick response.

I tried to reproduce the issue systematically and it turns out Git Bash / MSYS2 is not at fault — mv through MSYS2 does trigger the USN Journal correctly. My earlier bug report was based on a single observation that I couldn't reliably reproduce.

However, while collecting the debug log you asked for, I noticed something that may be interesting. The repro steps:

Everything 1.4.1.1032 (x64), Windows 10 Pro, NTFS volume (C:).
Enabled /verbose and /debug_log.
Ran in Git Bash:
mv "c:/Users/Sergey/.claude/plans/Архив/splendid-chasing-puppy.md" \
"c:/Users/Sergey/.claude/plans/splendid-chasing-puppy.md"
es.exe -w splendid-chasing-puppy.md — returns the correct new path.
The USN Journal records show up fine:

02:00:14.363: USN_RECORD 83677388592, FLAGS 00000020, PARENT FRN 027f00000000a833,
FRN 0416000000018097, reason RENAME_OLD_NAME (00001000),
filename splendid-chasing-puppy.md
02:00:14.368: USN_RECORD 83677388800, FLAGS 00000020, PARENT FRN 01ae00000003df05,
FRN 0416000000018097, reason RENAME_NEW_NAME (00002000),
filename splendid-chasing-puppy.md
02:00:14.375: USN_RECORD 83677388912, FLAGS 00000020, PARENT FRN 01ae00000003df05,
FRN 0416000000018097, reason CLOSE RENAME_NEW_NAME (80002000),
filename splendid-chasing-puppy.md
But a second later, when Everything tries to apply the rename, it logs:

02:00:15.335: unable to add ntfs file: splendid-chasing-puppy.md:
parent 01ae00000003df05 not found
And this is not unique to my mv — during the same second the log has 20+ similar entries for unrelated files from other processes:

02:00:49.674: unable to add ntfs file: v8_6205_2625.tmp: parent 00020000000462cb not found
02:00:49.683: unable to update file: v8_6205_2625.tmp: parent 00020000000462cb not found
02:00:49.773: unable to update file: 2026-04-15T17-17-06-022Z.jsonl: parent 024b00000010ffe3 not found
02:00:49.792: unable to add ntfs file: langsmith_state.json.lock: parent 00130000000e0828 not found
...
In this repro the index ended up correct anyway (presumably a retry or background rescan fixed it). But in the original case I reported, the stale path persisted until a manual reindex — which would be consistent with a missed rename when the retry path doesn't kick in.

So the real question for you isn't MSYS2, it's whether unable to add ntfs file: ... parent <FRN> not found under heavy disk activity can leave the index in a stale state when the deferred retry/rescan doesn't catch it.

Secondary question: is the USN processing in 1.5 Alpha the intended fix for this kind of race, or is 1.4 supposed to handle it reliably and this log is pointing at a real bug?

(Note on MSYS2 for context: mv in Git Bash goes through msys-2.0.dll → POSIX rename() → NtSetInformationFile/FileRenameInformation, not MoveFileW. It's a legal NT path, so USN works — but the Cygwin emulation adds extra steps like target-unlink and permission checks, which generate more USN traffic per logical move. That might be why I hit this race with bash mv but not with PowerShell Move-Item, even though both end up in the USN Journal.)

Full debug log (filtered to a 3-second window around the mv, ~1148 lines, 106 KB) attached: everything-msys2-repro.log.

Sorry for the initial misdirection.

[void]

Could you please send some additional logs:

• From an admin command prompt, please run:
  
  fsutil usn readdata c:\Users\Sergey\.claude\plans\Архив
• Please take note of the FileRef#, eg:
  0x00a30000001dd12f
• Please download voidtools dumpusn
• From an admin command prompt, please run:
  
  dumpusn c: 0x00a30000001dd12f
  
  where C: is the drive of the "c:/Users/Sergey/.claude/plans/Архив" folder from your initial test and
  where 0x00a30000001dd12f is the FileRef# from above.
  This will log the USN Journal entries for the missing folder in Everything.
• What is shown?

A common cause for missing folders in Everything is enabling any exclude filters under Tools -> Options -> Exclude.
Once a folder is excluded, it is always excluded, even when the folder should be included again.
For example, say you exclude system folders, the "subfolder" you created is initially created with the system attribute, which is removed later.
Everything will never see the system attribute removed, so will never re-add this folder.

Secondary question: is the USN processing in 1.5 Alpha the intended fix for this kind of race, or is 1.4 supposed to handle it reliably and this log is pointing at a real bug?

It's possible, but I would need to see USN journal logs to confirm.
Everything tracks folders with the FileRef#, so it seems unusual for a folder to be missing.
There's no changes to monitoring folders with the USN Journal in Everything 1.5.

(Note on MSYS2 for context: mv in Git Bash goes through msys-2.0.dll → POSIX rename() → NtSetInformationFile/FileRenameInformation, not MoveFileW. It's a legal NT path, so USN works — but the Cygwin emulation adds extra steps like target-unlink and permission checks, which generate more USN traffic per logical move. That might be why I hit this race with bash mv but not with PowerShell Move-Item, even though both end up in the USN Journal.)

The rename will eventually hit the NTFS driver, where the USN journal log entry is created.



Does the Архив folder show up in your Everything Index Journal?

• In Everything, from the Index menu, search for:
  
  c:\Users\Sergey\.claude\plans\Архив
• Are any results found?

Does forcing a rebuild pickup the missing Архив folder?

• In Everything, from the Tools menu, click Options.
• Click the Indexes tab on the left.
• Click Force Rebuild.
• Click OK.

[Serg2000Mr]

Here are the results:

fsutil usn readdata on c:\Users\Sergey\.claude\plans\Архив:


FileRef# : 0x0000000000000000027f00000000a833
Parent FileRef# : 0x000000000000000001ae00000003df05
dumpusn c: 0x0000000000000000027f00000000a833 — no output (no USN journal entries found for this folder).

[void]

Thank you for the USN journal entry information.

The USN Journal entry has likely been deleted. (overwritten)

Please try increasing your USN Journal size:
In Everything, from the Tools menu, click Options.
Click the NTFS tab on the left.
Select your C: drive.
Change Maximum size to 131072 KB.
(The default of 32768 KB will not even hold a days worth of changes on windows 10/11)

Please try the dumpusn process again if you notice a another missing file/folder.

[Serg2000Mr]

I have increased the size of the USN log as suggested, and I will continue monitoring.

Thank you for your time on this issue.