Bug: Desktop client 34.0.1 falsely flags new files as "locked", blocking sync for entire containing folder

[satz-nrw]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

After a file is added to a synced folder, the client immediately (and incorrectly) flags it as "locked" and then stops watching/syncing the entire containing folder — not just the one file. No further changes in that folder are picked up until the client is restarted. There is no actual OS-level lock on the file (verified via Windows Resource Monitor → Associated Handles, no process found holding the file, even with the PDF open in Adobe Acrobat).

Steps to reproduce

1. Start the Nextcloud desktop client (fresh start).
2. Add a new file to an already-synced folder → uploads correctly (first file after start works).
3. Add a second new file to the same folder shortly after.
4. The second file is flagged as "locked" and skipped. The whole containing folder stops syncing — no further uploads happen, even for unrelated new files, until the client is restarted.

Reproduced twice in a row with different filenames (test_1.pdf, then test_2.pdf after renaming/re-adding), same result both times.

Expected behavior

New files should sync normally; a (possibly false) lock detection on one file should not block sync for the rest of the folder.

Which files are affected by this bug

test_2.pdf

Operating system

Windows

Which version of the operating system you are running.

Windows 11

Installation method

Official Linux AppImage

Nextcloud Server version

34.0.2

Nextcloud Desktop Client version

34.0.1 (also reproduced on 34.0.0 before updating)

Did this occur after an update or on a clean installation?

Major version update (i.e. 4.0.0 → 33.0.0)

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• Default internal user-backend
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Log excerpt (debug log):

[ OCC::FileSystem::filePathLockFilePatternMatch ]: Checking if it is a lock file: "E:/Nextcloud-Sync/SATVISION/SV-2026-09/_PDFs/test_2.pdf"
[ info nextcloud.gui.folderwatcher ]: change on path "E:/Nextcloud-Sync/SATVISION/SV-2026-09/_PDFs/test_2.pdf"
[ OCC::Folder::pathIsIgnored ]: "E:/Nextcloud-Sync/SATVISION/SV-2026-09/_PDFs/test_2.pdf" is locked skip syncing it
[ OCC::WatcherThread::watchChanges ]: Skipping syncing of "E:/Nextcloud-Sync/SATVISION/SV-2026-09/_PDFs"

This fires within milliseconds of the file appearing in the folder — before any application (including Adobe Acrobat, tested afterward) could plausibly hold a lock on it. Checked with Resource Monitor (Associated Handles) at that point: no process holds a handle on the file.

Restarting the client triggers a fresh local discovery which correctly reports `isLocked false` for the same file, and sync resumes.

Additional info

Sync folder on a mapped drive (E:\Nextcloud-Sync...)

Debug archive with full logs available on request (not attaching publicly due to server URL/account info).

[Rello]

Hello,
just to confirm, its windows - not linux, correct?

[satz-nrw]

Hello, just to confirm, its windows - not linux, correct?

nextcloud itself is installed on linux
the desktop app on windows 11

[Rello]

quick check via Codex:

Exact failure path

• Windows reports the new file.
• FolderWatcher correctly emits the file path.
• Folder::slotWatchedPathChanged() calls pathIsIgnored().
• pathIsIgnored() performs a synchronous Win32 lock probe.
• A sharing or byte-range lock violation makes it return early at folder.cpp:1006
• Consequently, the path is never added to local discovery at folder.cpp:681, and no sync is scheduled at folder.cpp:739.
• The lock probe uses CreateFileW followed by LockFile; either ERROR_SHARING_VIOLATION or ERROR_LOCK_VIOLATION is classified as locked in filesystembase.cpp:732.

Resource Monitor showing no handle afterward does not prove the probe was false—it could have been a short-lived copy/SMB lock. But whether the lock was real or transient, permanently dropping the notification is the bug.

can you confirm that E: is an SMB share?

[satz-nrw]

No. E: is a local ssd drive.

But I do have a drive mapped to a smb share (I suppose you mean Samba?). But the app is not configured to touch that in any way.

---

(I was using claude to help me figure out the problem and he/it(?) compiled the bug report. My programming knowledge comes down to a bit of javascript.)

[Rello]

thank you. is the issue reproducible?
because it seems to be a very edge case that might come down to some milliseconds of file operations by the windows system. Looking at the number of downloads and the reported issues, it does not seem to be a general one

[satz-nrw]

Sadly it happens all the time.
The first time I start the app syncing happens. Any new files to the folder don't get synced anymore until I restart the app.
Restarting the computer, the nexcloud or the nexcloud host doesn't make a difference.

[Rello]

that helps - because you can evaluate a fix. we will get back