Bug description
Copied/newly-created files inside a synced folder remain stuck in "pending sync" (item stays queued but the sync never actually starts / no upload happens). The sync only kicks off for that stuck file after another, unrelated change happens in the same folder (e.g. modifying a different file, or later modifying the stuck file itself). This behavior is reproducible across all our desktop clients (widespread, not limited to one machine or user).
This strongly suggests the local filesystem/folder watcher is failing to fire (or fires an incomplete event) for file creation via copy, and the stuck file only gets picked up later when a full/periodic discovery run is triggered by a different filesystem event.
Steps to reproduce
- On a machine with Nextcloud Desktop 34.0.1 connected to a Nextcloud server, open a folder that is actively synced.
- Copy an existing file (or a new file) into that synced folder (via File Explorer / Finder, i.e. not through the Nextcloud client itself).
- Observe the client tray icon / sync status: the file shows as pending/queued but the actual upload never starts, even after waiting several minutes.
- Modify a different file in the same folder (or touch/modify the originally copied file).
- Observe: sync immediately starts and processes both the new change and the previously stuck file.
Expected behavior
Newly copied/created files should be detected and synced by the local filesystem watcher without requiring an unrelated triggering event elsewhere in the folder.
Actual behavior
The copied file sits in a "pending"/queued sync state indefinitely until some other filesystem event in the same synced folder happens to trigger a discovery run.
Environment
• Nextcloud Desktop Client version: 34.0.1
• Nextcloud Server version: 33.0.7
• OS: Windows (AD domain-joined clients)
• Scope: Reproducible widely across multiple clients/users, not isolated to one machine
Additional context
• We are currently running desktop clients one major version ahead of the server (client 34.0.1 vs. server 33.0.7). We have not yet been able to confirm whether this version gap is a contributing factor or whether the issue is purely client-side (folder watcher regression in the 34.x line).
• Happy to provide a full debug archive on request.
Is this a regression?
Unclear — this class of "copied file stuck until unrelated change" watcher issue has been reported in various forms across multiple past Nextcloud Desktop versions, but we have not found an exact match for this specific 34.0.1 + server 33.0.7 combination in existing open issues.
Bug description
Copied/newly-created files inside a synced folder remain stuck in "pending sync" (item stays queued but the sync never actually starts / no upload happens). The sync only kicks off for that stuck file after another, unrelated change happens in the same folder (e.g. modifying a different file, or later modifying the stuck file itself). This behavior is reproducible across all our desktop clients (widespread, not limited to one machine or user).
This strongly suggests the local filesystem/folder watcher is failing to fire (or fires an incomplete event) for file creation via copy, and the stuck file only gets picked up later when a full/periodic discovery run is triggered by a different filesystem event.
Steps to reproduce
Expected behavior
Newly copied/created files should be detected and synced by the local filesystem watcher without requiring an unrelated triggering event elsewhere in the folder.
Actual behavior
The copied file sits in a "pending"/queued sync state indefinitely until some other filesystem event in the same synced folder happens to trigger a discovery run.
Environment
• Nextcloud Desktop Client version: 34.0.1
• Nextcloud Server version: 33.0.7
• OS: Windows (AD domain-joined clients)
• Scope: Reproducible widely across multiple clients/users, not isolated to one machine
Additional context
• We are currently running desktop clients one major version ahead of the server (client 34.0.1 vs. server 33.0.7). We have not yet been able to confirm whether this version gap is a contributing factor or whether the issue is purely client-side (folder watcher regression in the 34.x line).
• Happy to provide a full debug archive on request.
Is this a regression?
Unclear — this class of "copied file stuck until unrelated change" watcher issue has been reported in various forms across multiple past Nextcloud Desktop versions, but we have not found an exact match for this specific 34.0.1 + server 33.0.7 combination in existing open issues.