External deletion of NFD-normalized filenames on HFS+ leaves stale entries on macOS

[senosa]

Title: External deletion of NFD-normalized filenames on HFS+ leaves stale entries in the file list on macOS

What system are you running Yazi on?

macOS 26.6.2 (25G83), Apple Silicon.

The affected volume is a local, journaled HFS+ volume:

/dev/disk6s2 on /Volumes/Data3 (hfs, local, nodev, nosuid, journaled, noowners)

yazi --debug output

Reproduced with both Homebrew Yazi 26.8.15 and 26.9.1.

Yazi
    Version: 26.9.1 (Homebrew 2026-09-01)
    Debug  : false
    Triple : aarch64-apple-darwin (macos-aarch64)
    Rustc  : 1.98.0 (88d9e12a 2026-08-18)

Ya
    Version: 26.9.1 (Homebrew 2026-09-01)
    Debug  : false
    Triple : aarch64-apple-darwin (macos-aarch64)
    Rustc  : 1.98.0 (88d9e12a 2026-08-18)

Describe the bug

When a file on an HFS+ volume has a filename that is normalized to NFD by the filesystem, deleting it externally leaves a stale entry in Yazi's normal directory view.

The file no longer exists on disk, but remains displayed until I leave the directory and enter it again. Focusing Yazi also refreshes the list.

This does not reproduce with an ASCII-only filename on the same volume.

Minimal reproducer

1. Create and enter a directory on a local HFS+ volume:

   mkdir -p /Volumes/Data3/yazi-nfd-test
   yazi /Volumes/Data3/yazi-nfd-test

2. From another terminal, create a file using NFC input:

   touch '/Volumes/Data3/yazi-nfd-test/プ.webm.part'

3. Confirm that the file appears in Yazi.

4. Delete it externally:

   rm '/Volumes/Data3/yazi-nfd-test/プ.webm.part'

Expected behavior

プ.webm.part should disappear from Yazi immediately.

Actual behavior

The entry remains visible indefinitely, despite the file being absent on disk.

On HFS+, the filename is listed in NFD form:

プ.webm.part

The same test with an ASCII-only name, for example before.webm.part, updates immediately.

Additional context

I originally noticed this while gallery-dl was downloading Pixiv ugoira files and converting them to WebM. gallery-dl deletes a temporary .webm.part file after conversion, so many stale entries accumulated in Yazi.

I ruled out gallery-dl, mkvmerge, write volume, event volume, terminal emulator, and window focus as root causes:

• ASCII create/write/rename/delete operations update immediately.
• Creating a final WebM and immediately deleting a .part also updates immediately with ASCII names.
• The NFD-normalized one-character filename above is sufficient to reproduce the stale deletion entry.
• Reproduced in the normal directory view, not a search view.
• Reproduced with Yazi 26.8.15 and current Homebrew stable 26.9.1.

This appears to be an NFC/NFD path-equivalence issue in Yazi's macOS file-watcher handling, or in a dependency used by that layer.