Expected behaviour
Typing in the note editor should remain responsive, even when the note folder is on a network share, even over a higher-latency link such as a VPN.
Actual behaviour
On QOwnNotes 26.x, typing in the editor freezes for several seconds after every 3–4 words when the note folder lives on an SMB share accessed through a VPN tunnel. The UI becomes unusable for remote editing.
A Process Monitor (Sysinternals) trace shows that a single keystroke produces ~60 file-system calls from QOwnNotes.exe, roughly two-thirds of them CreateFile / QueryOpen / ReadFile / LockFile / QueryStandardInformationFile against .md files in the note folder other than the currently edited note. On a local LAN connection these calls are imperceptible; over a VPN with ~30 ms RTT each call becomes a network round-trip, and they accumulate into multi-second freezes. The QOwnNotes log panel (debug level) is silent during the freezes — i.e. nothing in the app's own event flow is logged while the file-system traffic happens.
Steps to reproduce
Place the note folder on an SMB share reachable over a VPN tunnel.
Open a note containing some Markdown links / image links to other notes/media.
Type continuously.
Observe multi-second editor freezes recurring every few words.
Workaround / regression bisection
Downgrading to 25.12.1 fully resolves the issue over the same VPN/SMB connection — typing is fluid, autosave fires at the configured interval, no freezes.
This points to a regression introduced somewhere between 25.12.1 and current 26.x. Likely candidates from the changelog:
26.3.3 "small inline Markdown image previews … in the note text edit" (enabled by default) — would touch external files on every editor change.
26.2.10 "notes directory watcher now always schedules a deferred re-index" plus "note index rebuild also refreshes the note list when an existing note's content was updated on disk" — would explain enumeration of all .md files in the folder on save.
Environment
OS: Windows 11
QOwnNotes (broken): 26.x (latest)
QOwnNotes (working): 25.12.1
Note folder: SMB share on a Linux system, accessed via VPN
notes.sqlite: ~36 KB
Windows-side checks done and ruled out: Defender exclusions set, Offline Files / CSC service stopped, indexing on the share disabled, MTU verified, no other process touching the share during the freezes (Procmon-confirmed: only QOwnNotes.exe).
Additional notes
Given that the file-system calls during the freezes target .md files other than the note being edited, the regression appears to involve either the directory watcher's re-index path or a feature that scans linked/related notes on each editor event. The Procmon trace and the clean 25.12.1 vs broken 26.x bisection should make this reproducible without VPN if a similar high-latency filesystem (e.g. a slow USB drive, a throttled network mount, or a slowfs-style FUSE mount) is used to amplify the per-call cost.
Expected behaviour
Typing in the note editor should remain responsive, even when the note folder is on a network share, even over a higher-latency link such as a VPN.
Actual behaviour
On QOwnNotes 26.x, typing in the editor freezes for several seconds after every 3–4 words when the note folder lives on an SMB share accessed through a VPN tunnel. The UI becomes unusable for remote editing.
A Process Monitor (Sysinternals) trace shows that a single keystroke produces ~60 file-system calls from QOwnNotes.exe, roughly two-thirds of them CreateFile / QueryOpen / ReadFile / LockFile / QueryStandardInformationFile against .md files in the note folder other than the currently edited note. On a local LAN connection these calls are imperceptible; over a VPN with ~30 ms RTT each call becomes a network round-trip, and they accumulate into multi-second freezes. The QOwnNotes log panel (debug level) is silent during the freezes — i.e. nothing in the app's own event flow is logged while the file-system traffic happens.
Steps to reproduce
Place the note folder on an SMB share reachable over a VPN tunnel.
Open a note containing some Markdown links / image links to other notes/media.
Type continuously.
Observe multi-second editor freezes recurring every few words.
Workaround / regression bisection
Downgrading to 25.12.1 fully resolves the issue over the same VPN/SMB connection — typing is fluid, autosave fires at the configured interval, no freezes.
This points to a regression introduced somewhere between 25.12.1 and current 26.x. Likely candidates from the changelog:
26.3.3 "small inline Markdown image previews … in the note text edit" (enabled by default) — would touch external files on every editor change.
26.2.10 "notes directory watcher now always schedules a deferred re-index" plus "note index rebuild also refreshes the note list when an existing note's content was updated on disk" — would explain enumeration of all .md files in the folder on save.
Environment
OS: Windows 11
QOwnNotes (broken): 26.x (latest)
QOwnNotes (working): 25.12.1
Note folder: SMB share on a Linux system, accessed via VPN
notes.sqlite: ~36 KB
Windows-side checks done and ruled out: Defender exclusions set, Offline Files / CSC service stopped, indexing on the share disabled, MTU verified, no other process touching the share during the freezes (Procmon-confirmed: only QOwnNotes.exe).
Additional notes
Given that the file-system calls during the freezes target .md files other than the note being edited, the regression appears to involve either the directory watcher's re-index path or a feature that scans linked/related notes on each editor event. The Procmon trace and the clean 25.12.1 vs broken 26.x bisection should make this reproducible without VPN if a similar high-latency filesystem (e.g. a slow USB drive, a throttled network mount, or a slowfs-style FUSE mount) is used to amplify the per-call cost.