[Bug]: Windows Client completely ignores new files added to synced folders (No F12 logs generated) - Fixed by Downgrade

[slobozzzzz]

⚠️ 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've searched 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

Environment:

OS: Windows 11

Nextcloud Desktop Client Version: 33.0.3

Nextcloud Server Version: 33.0.3

Issue Summary:
After a recent update, the Nextcloud Windows desktop client completely stopped detecting new files added to locally synchronized folders. When a new file (e.g., a .wav file or a .png screenshot) is placed inside an existing synced folder via Windows Explorer, the client does not initiate a sync. The file is simply ignored.

Steps to Reproduce:

Have a fully synced local folder on the Windows client.

Copy and paste a new file (e.g., a .png screenshot or .wav audio file) into this synced folder using Windows Explorer.

Observe the Nextcloud client activity.

Expected Behavior:
The client should detect the file system change instantly, trigger the sync process, and upload the file to the server.

Actual Behavior:
The client does absolutely nothing. The file remains unsynced.

If I press F12 to open the debug log window and drop a new file into the folder, absolutely nothing is printed in the log output. It seems the local file system watcher/sensor is broken and not receiving OS events.

Uploading the exact same file via the Web UI works flawlessly.

Creating a brand new folder inside the synced directory and placing the file there sometimes forces a sync for that specific item, but regular drops in existing folders are ignored.

Troubleshooting Steps Taken (None worked):

Restarted the server and ran occ files:scan --all and occ maintenance:data-fingerprint to ensure no server-side ETag mismatch. (WebDAV is fully functional).

Signed out, removed the account, and deleted %appdata%\Nextcloud and %localappdata%\Nextcloud for a clean install.

Created a brand new local folder (Test_Folder) and linked it to a new server folder via "Add folder sync connection".

Disabled "Virtual Files" and forced "Local sync" (Sync everything locally).

Checked the "Ignored Files" list to ensure the file extensions weren't blocked.

The Solution / Workaround:
The only way to fix this issue was to completely uninstall the current client version and downgrade to the previous version (33.0.0).
Immediately after downgrading and setting up the sync connection again, the client successfully detected all file changes and synced everything instantly without any issues. The green overlay icons also returned after a Windows Explorer restart.

It appears the local file system watcher or the Virtual Files integration in the latest release is severely bugged on Windows, completely breaking local-to-server uploads for existing folders.

Steps to reproduce

Steps to Reproduce:

Have a fully synced local folder on the Windows client.

Copy and paste a new file (e.g., a .png screenshot or .wav audio file) into this synced folder using Windows Explorer.

Observe the Nextcloud client activity.

Expected Behavior:
The client should detect the file system change instantly, trigger the sync process, and upload the file to the server.

Actual Behavior:
The client does absolutely nothing. The file remains unsynced.

Expected behavior

Expected Behavior:
The client should detect the file system change instantly, trigger the sync process, and upload the file to the server.

Which files are affected by this bug

I tested with multiple file types (audio, images, text), and all of them were ignored. Some specific examples include: test.wav screenshot.png {A6BFA3BA-244F-4F05-81A6-394352B9A6A6}.png (this was explicitly generated by the Nextcloud client logs as a reference file during my tests)

Operating system

Windows

Which version of the operating system you are running.

11

Package

Official Windows MSI

Nextcloud Server version

33.0.3

Nextcloud Desktop Client version

33.0.3

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.16.1 to 3.16.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

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

Nextcloud Server logs

Additional info

No response

[Lat3magnet1c]

same problem here

[Narrat]

What also works for me as workaround is to quit the program and start it anew. On startup it detects and syncs the changes.

[R0BATZEN]

Same problem, same exact version number, although I'm still on Windows 10 and not 11.

What also works for me as workaround is to quit the program and start it anew. On startup it detects and syncs the changes.

Unfortunately this does not work for me. No matter how many times I restart either nextcloud or my whole pc, the problem still exists.

[koenbokern]

Without knowing the exact impact of the rest of the 33.0.3 changes, would this issue not warrant the removal of this version from the update server since it impacts syncing (and therefore sharing)? This would help organizations who don't manage the software of their users by not having to communicate both this issue and the resolution.
Edit: The new 33.0.4.release with the fix is appreciated a lot.

[Rello]

Without knowing the exact impact of the rest of the 33.0.3 changes, would this issue not warrant the removal of this version from the update server since it impacts syncing (and therefore sharing)? This would help organizations who don't manage the software of their users by not having to communicate both this issue and the resolution. Edit: The new 33.0.4.release with the fix is appreciated a lot.

Hello,

0.3 was revoked already on Friday. Even so we have a lot of automated tests already, we don´t claim them to be perfect. If we see high number of responses to single issues, we go for a removal to be on the safe side.

0.4 was released today. please report back if the error still exists