fix: use FSEvent on macos to avoid Too many files

[gaojunran]

PR #39 originally introduced macos_kqueue because FSEvents was believed to only report directory-level notifications, which would break pf watch and pf logs -t. However, in notify v8, the FSEvents implementation hardcodes the kFSEventStreamCreateFlagFileEvents flag, which enables file-level event reporting.

Fixes #298.

[greptile-apps]

Greptile Summary

This PR removes the macos_kqueue feature flag from the notify v8 dependency in Cargo.toml, allowing the default macos_fsevent (FSEvents) backend to be used on macOS instead of kqueue. This fixes the "Too many open files" (EMFILE) error that kqueue caused by opening a file descriptor for every watched path. The fix is safe because notify v8's FSEvents backend hardcodes kFSEventStreamCreateFlagFileEvents, which enables file-level event granularity — meaning pf watch and pf logs -t will continue to receive per-file change notifications rather than only directory-level ones.

• Root cause addressed: macos_kqueue opened one fd per watched file; large projects exceeded the OS file descriptor limit.
• No functional regression: notify v8 FSEvents reports file-level events via the hardcoded kFSEventStreamCreateFlagFileEvents flag, so all existing glob/pattern matching in watch_files.rs works unchanged.
• Platform scope: The change only affects macOS; Linux (inotify) and Windows (ReadDirectoryChangesW) are unaffected.
• Cargo.lock note: Only Cargo.toml was changed; Cargo.lock still references kqueue as a resolved package. Cargo does not store feature selections in the lockfile — features are resolved fresh per build from Cargo.toml — so regenerating the lockfile via cargo build or cargo update after merging will cleanly drop the now-unused kqueue and mio entries.

Confidence Score: 5/5

Safe to merge — single-line dependency feature removal with a well-understood correctness basis and no functional regression.

The change is minimal and surgical (one line in Cargo.toml). The technical claim is verifiable: notify v8's FSEvents backend hardcodes kFSEventStreamCreateFlagFileEvents, and the default feature for macOS in notify v8 is macos_fsevent. The file-watching logic in watch_files.rs uses RecommendedWatcher and only cares about EventKind::Modify/Create/Remove, all of which FSEvents reports at file granularity. No P1 issues were found.

No files require special attention.

Important Files Changed

Filename	Overview
Cargo.toml	Removes the macos_kqueue feature flag from the notify v8 dependency, letting the default macos_fsevent (FSEvents) backend be used on macOS — fixes "Too many open files" while preserving file-level event granularity via kFSEventStreamCreateFlagFileEvents.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[File Change on macOS] --> B{Before PR
macos_kqueue feature}
    B --> C[kqueue backend
opens 1 fd per watched file]
    C --> D[EMFILE: Too many open files]

    A --> E{After PR
default macos_fsevent feature}
    E --> F[FSEvents backend
kernel-level event stream]
    F --> G[kFSEventStreamCreateFlagFileEvents
hardcoded in notify v8]
    G --> H[File-level events reported
no fd per file]
    H --> I[WatchFiles / RecommendedWatcher
receives EventKind::Modify/Create/Remove]
    I --> J[path_matches_patterns checks glob patterns]
    J --> K[Daemon restarted if pattern matches]

Loading

_{Reviews (1): Last reviewed commit: "fix: use fsevent on macos to avoid `Too ..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request updates the Cargo.toml file by removing the macos_kqueue feature from the notify dependency. I have no feedback to provide as there are no review comments to evaluate.