Critical: Disk exhaustion on Windows due to massive SQLite WAL growth (50GB+) caused by cross-platform sync error loops

[freudenfranz]

Description
On the Windows client, the local SQLite database Write-Ahead Log (.db-wal) grows indefinitely until it fills the entire hard drive (observed size > 50GB). This causes the sync client to crash and the OS to run out of space.

Steps to reproduce

1. Setup kDrive on a Linux machine.
2. Allow Linux system folders like .Trash-1000 or lost+found, or files with Windows-illegal characters (e.g., Image:Name.jpg, File .txt) to sync to the cloud.
3. Connect a Windows kDrive client to the same account.
4. The Windows client attempts to download these files.
5. Observe the .db-wal file size in %LocalAppData%\kDrive growing rapidly until disk space is 0.

Expected behavior
The Windows client should safely skip or ignore folders/files incompatible with Windows and should not generate an error loop that floods the SQLite WAL, risking exhaustion of disk space.

Key Log Evidence
The logs show a massive flood of error signals followed by database write failures:

2026-02-04 11:36:15:794 [I] (3000) tmpblacklistmanager.cpp:41 - *1* Item added in error list ...
2026-02-04 11:36:15:797 [D] (1776) oldcommserver.cpp:289 - Snd sgnl 10 UTILITY_ERROR_ADDED(26)
... [Repeated thousands of times] ...
2026-02-04 11:41:13:790 [W] (3000) db.cpp:420 - ERROR committing to the database: database or disk is full
2026-02-04 11:41:13:863 [D] (3000) db.cpp:413 - Database Transaction is running, not starting another one!

Environment

• Client: Windows kDrive Desktop Client
• Sync Setup: Cross-platform sync between Linux and Windows nodes
• Affected File: .sync_[node_id].db-wal

Root Cause Analysis (Derived from Logs)

• The issue is triggered when the Windows client attempts to sync specific folders originating from a Linux environment that contain incompatible file names or system folders.
• E.g. the Linux Trash folder (.Trash-1001) and the lost+found folder were synced.
• The Windows client processes these files, encounters a file system naming violation (likely reserved characters like :, trailing spaces, or reserved names), and generates an internal error signal (UTILITY_ERROR_ADDED).
• The client enters an infinite loop, generating thousands of errors per minute. Every error is written to the SQLite database. Due to high frequency of writes, SQLite cannot perform a checkpoint (merge WAL back to DB), causing the WAL file to grow uncontrollably until disk exhaustion (13 - database or disk is full).

Suggested Fixes for Developers

• Default Exclusions: The Windows client must strictly enforce a default ignore list for known Linux system folders (.Trash-*, lost+found) and enforce Windows filename compliance before attempting the DB write/sync operation to prevent the error loop.
• Safety Valve: Implement a check on the SQLite WAL size. If it exceeds a reasonable limit (e.g., 2GB), force a checkpoint or halt the sync process to protect the user's disk space.
• Transaction Handling: Prevent the error logging mechanism from keeping a database transaction open indefinitely during high-frequency failure events.

Additional context
Problem causes data loss and full OS crash on user systems. A permanent fix is needed to prevent recurrence.