Nexctcloud client 34.0.2 not syncing

[wolfgang-demeter]

⚠️ 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

@camilasan This is the new bug report, originating in #10513

Version 34.0.2 of the Nextcloud Client for Windows is still not working for me - upgraded from 33.0.7 and many versions before.

• I created a local file nextcloud-test-sync\nextcloud-upload-test-sync.odt which never gets uploaded to the server.
• I created a file nextcloud-download-test-sync.md (the folder nextcloud-test-sync from before also doesn't get "uploaded") on the server. It never gets downloaded to the client.

Switched back to 33.0.7 and both directions synced immediately.

I have a Nextcloud debug archive of the actions, but i found not a single mention of the files created in the 20260820_0710_nextcloud.log.0.

In regard to #10513 (comment)

Have you tried to temporarily disable the windows defender realtime scanning? Pause the nextcloud sync, disable the scanning, start the sync and wait a bit. Not a solution but a workaround for the time being.

That seemed to work. And it seems like it survives a restart of the Nextcloud client. But i am not sure, is this a lasting solution on my Windows laptop? And it's certainly not a solution for other managed Windows clients, therefore i am keeping those clients on 33.0.7 for the moment.

Steps to reproduce

• I created a local file nextcloud-test-sync\nextcloud-upload-test-sync.odt which never gets uploaded to the server.
• I created a file nextcloud-download-test-sync.md (the folder nextcloud-test-sync from before also doesn't get "uploaded") on the server. It never gets downloaded to the client.

Expected behavior

Files should sync

Which files are affected by this bug

multiple files on client and server

Operating system

Windows

Which version of the operating system you are running.

Windows 11 Pro 25H2 (26200.9168)

Installation method

Official Windows MSI

Nextcloud Server version

34.0.3

Nextcloud Desktop Client version

34.0.2

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

Additional info

No response

[camilasan]

did you ever edited nextcloud-test-sync\nextcloud-upload-test-sync.odt?
I am wondering if this has to do with locking.
We still have this issue opened #10439.

[wolfgang-demeter]

did you ever edited nextcloud-test-sync\nextcloud-upload-test-sync.odt?

No, i did not edt the file nextcloud-test-sync\nextcloud-upload-test-sync.odt (right click -> new -> *.odt file). I also created a unedited *.bmp file in the folder as well as the Nextcloud Debug archive. None of it got synced

The *.md files i created on the server I edited however with the Nexctcloud Editor, and they also didn't get downloaded.

---

I testeted all this this morning, about 3 to 4 hours ago. And i have the Nexctcloud client 34.0.2 installed since then. It's running for a couple of ours now and it seems to work fine. However a couple of minutes ago, i got a down-Notification from my Nextcloud server and all PHP processes were gone - which never happened before as far as i can recollect. Might this be correlated?

[adi-dev]

I just noticed that multiple files aren't being uploaded to the server - I copied 160 photos into a folder, only 100 got uploaded. I tried to restart, force resync, change networks, but no luck. Desktop client v34.0.2

[Githopp192]

i think same issue as in 34.0.0 .. in 34.0.1 and now in 32.0.2

Status will not come back ..

i think i have again to downgrade to the last stable version 33.07 ..

new status: now - after about 20 minutes .. the status come back with "sync successfull" .. hope this status wil not change .. and syncs are working .. (still on 34.0.2)

[Githopp192]

after some days of testing .. no 34.0.2 is not working - same issue as in 34.0.0 / 34.0.1 - always saying "sync is preparing" when on only one little file need to be updated ... need again to downgrade to 33.07 definitively

[Githopp192]

tried another pc from another person with 34.0.2 - same behave - looping with this message -->

Also - Explore will show syncing iconf for ever ... no sync will happen .. when it will happen, then it needs 1/2h for a size of about 200KB !

Now with 34.0.2 put two json files to the Nextcloud dir - total 7K - took 10 minutes to get synced.
Tried to pause sync, force resync - nothing helped.

Environment with push-agent

[Githopp192]

Now with 34.0.3 - no change - message "waiting for synchronization" for ever ..
Syncing very small files (4K) need 20 minutes ..

[ralftar]

@camilasan — the part of this report where the client says "waiting for synchronization" for
half an hour, and kilobytes take minutes, is the cost of one local discovery pass, not a
transfer failure.

Since #9810 landed in 34.0.0, FileSystem::isFileLocked() runs once per regular file on every
local discovery pass, and on Windows that is a CreateFileW with GENERIC_READ per file:
https://github.com/nextcloud/desktop/blob/v34.0.4/src/libsync/discoveryphase.cpp#L412-L417
Sync cannot start until the pass finishes, so the wait scales with the file count and the
per-file latency of the disk, not with what is being synced. That matches 7 KB taking ten
minutes here, and 34.0.2 and 34.0.3 behaving the same.

It is unchanged in v34.0.4. Same root cause in #10580, #10613 and #10687, and in #10491 and
#10513, which are closed as completed while the per-file open remains.

Measurements on 34.0.3 (@joseph-valenti, two machines, same tree, rollback-verified): sync duty
cycle 2% → 85% on a USB HDD, 12% → 36% on NVMe, both back to baseline on 33.0.7.
#10491 (comment)

I opened #10850 with a fix and two tests. It builds on your #10500: the check stays on the
worker thread, and a file that still matches its journal record in a directory the server
reports unchanged is skipped, since its lock state cannot change the outcome. Every workflow on
the pull request sits at action_required, so nothing has compiled yet — could you approve the
run?

The slowness reported here is the same bug as #10580, #10613 and #10687. The part inherited from #10513, where files do not transfer at all, is a different path through the same call and is not what #10850 changes.

[Githopp192]

@ralftar - my compliments .. this looks like a good rca action. Thx - well done.