feat(node): skip a file the disk stops answering for, then pause its root

A Windows tester's scan stuck for good on one directory of a large disk:
one read that never returned held the indexer's only thread, and with it
every root behind that one.

- A disk call is timed by its silence, not its length: each directory
  entry listed and each megabyte read counts as an answer. After 60 s of
  silence the call is abandoned on its daemon thread, the file is noted
  unread and the scan goes on.
- Three silent files in a row pause the root (not persisted). Resume
  skips the files already known to give no answer; a restart, a replug
  or a change to the file retries them.
- The walk is per directory with os.scandir: a subdirectory that cannot
  be listed costs itself, and a listing that stops answering pauses the
  root at once. A scan no longer stats anything from the event loop.
- The log names the file after 10 s of silence, the indexing band shows
  it, and Group settings shows the paused root, where it stuck and the
  unread files with their reason, on the node's machine only.
- generate_http_api.py writes LF on Windows too.

Verified with real kernel-blocked opens (an unacknowledged oplock) in the
installed frozen app.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 19 insertions, 0 deletions

diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index 9d1749f..bab2074 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -702,6 +702,19 @@ Nothing else in that directory is indexed until you click **Resume indexing**,
 not even a file a member uploads into it, and the pause survives a restart.
 Resuming picks up where it stopped: files already indexed are not read again.
 
+**A disk that stops answering.** A failing drive, a network share that dropped
+or a file a sync client has not downloaded can leave a read waiting for ever.
+The node waits sixty seconds for an answer, then leaves that file and goes on.
+After three such files in a row it takes the disk to be the problem and pauses
+that directory by itself; the other directories go on being indexed, and what
+was already indexed stays visible. On the node's own machine, the indexing band
+names the file once the disk has been silent for ten seconds, and Group →
+Settings shows **disk not answering** on the directory, where it stopped, and
+the list **Files that could not be read** with the reason for each. Check the
+disk, or move those files out, then click **Resume indexing**: the node gets
+past the files it already knows give no answer, and tries them again when they
+change or when it restarts.
+
 One thing that surprises people: **two identical files in one group are one
 entry**, because a file is identified by its content. A scan that reports ten
 files and indexes nine has not lost anything.
@@ -1037,6 +1050,12 @@ Choose a download folder in Settings → Downloads, which switches the browser t
 writing straight to disk, and retry. The desktop application does not have this
 class of problem.
 
+**Indexing stops on one directory, or some of its files never appear.**
+Group → Settings, on the node's own machine: a directory marked **disk not
+answering** was paused by the node, and **Files that could not be read** lists
+what it gave up on and why. See Indexing in section 6. The node's log names
+the same files (`No answer from the disk`, `Cannot index`).
+
 **Nothing appears in Videos, Music or Photos.**
 No folders have been chosen for that application yet. Group → Settings. The tab
 says so rather than just looking empty, but it is easy to miss.