[Bug]: VFS sync engine involuntarily deletes folders on Windows 33.0.x regression not present in 4.0.8

[mfeddani]

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

The share dialog is looking incomplete.On Windows with Virtual Files (VFS) mode enabled, the sync engine involuntarily deletes folders and specific files from shared directories during normal sync operations. Deletions happen silently, without any user action, and are sent to the Nextcloud trashbin.

This is a regression introduced in the 33.0.x series, the issue is not reproducible on macOS and not present in 4.0.8.

We have server-side evidence of 11,000+ blocked deletion attempts in 48 hours across ~30 Windows users, all running 33.0.1 or 33.0.2. Users who were downgraded to 4.0.8 show zero deletion attempts after the downgrade.

Measured over 48 hours on a ~30-user Windows environment (all on 33.0.2), with server-side blocking in place:

2026-04-16 | ~9,740 files
2026-04-17 (morning only) | ~1,523 files

Steps to reproduce

Install Nextcloud Desktop 33.0.1 or 33.0.2 on Windows 10/11
Enable Virtual Files (VFS) sync mode on a shared folder (e.g. /CAO/, /GENERAL/)
Open a file in the synced directory with a CAD application (SolidWorks, AutoCAD) — this creates lock files (.dwl, .dwl2, .lck)
Close the application; lock files are deleted locally
Observe: the sync engine sends DELETE requests for parent folders, not just the lock files.

Expected behavior

Only the lock files (or the specific modified files) should be affected. Parent folder structure must never be deleted as a side effect of a file-level sync operation.

Actual Behavior

The sync engine resolves a local "delete/new" conflict by choosing deletion for the parent folder. The folder — and all its contents — is sent to the Nextcloud trashbin without any user confirmation or warning.

Server log pattern observed:

DELETE /remote.php/dav/files/{user}/CAO/01 CLIENTS/{client}/{project}/{subfolder}
User-Agent: Mozilla/5.0 (Windows) mirall/33.0.2 (build 20260331)
The deletions target intermediate folders deep in the tree (e.g. 03 Etudes, 05 Achat, PLANS) — not the root share.

Which files are affected by this bug

/CAO/01 CLIENTS/{client}/{project}/03 Etudes /CAO/01 CLIENTS/{client}/{project}/04 Données d'entrée /CAO/01 CLIENTS/{client}/{project}/05 Achat /TRAITEMENT/4 - DEVIS/{client}/{project}/03 - Offres de prix /COMMUN/PROCESSUS REALISATION/R3. PRODUCTION/CONTROLE QUALITE /COMMUN/PROCESSUS REALISATION/R3. PRODUCTION/MODE OPERATOIRE /CAO/01 CLIENTS/{client}/{project}/07 Liste des livrables.xlsx

Operating system

Windows

Which version of the operating system you are running.

Windows 11

Package

Official Windows MSI

Nextcloud Server version

33.0.1

Nextcloud Desktop Client version

33.0.1 and 33.0.2

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

Fresh desktop client install

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

Pattern : multiple consecutive DELETE requests targeting sibling subfolders of the same project directory within the same second — strongly suggesting a conflict resolution cascade, not intentional user action.

{
  "time": "2026-04-17T08:07:28+00:00",
  "level": 2,
  "method": "DELETE",
  "url": "/remote.php/dav/files/USER/TRAITEMENT/4%20-%20DEVIS/{client}/{project}/05%20-%20RETROPLANNING",
  "message": "Folder deletion blocked: /USER/files/TRAITEMENT/4 - DEVIS/{client}/{project}/05 - RETROPLANNING",
  "userAgent": "Mozilla/5.0 (Windows) mirall/33.0.2 (build 20260331) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version": "33.0.1.2"
}
{
  "time": "2026-04-17T08:07:45+00:00",
  "level": 2,
  "method": "DELETE",
  "url": "/remote.php/dav/files/USER/CAO/01%20CLIENTS/{client}/{project}/07%20Liste%20des%20livrables.xlsx",
  "message": "Protected file deletion blocked: /USER/files/CAO/01 CLIENTS/{client}/{project}/07 Liste des livrables.xlsx",
  "userAgent": "Mozilla/5.0 (Windows) mirall/33.0.2 (build 20260331) (Nextcloud, windows-10.0.26200 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version": "33.0.1.2"
}

Additional info

Additional Context

This appears related to:

#8983 — random file/folder deletions reported on 4.0.0
PR #8671 — "folder delete/new conflict will be 'delete'" — merged Oct 7 2025, but the regression appears to persist in 33.0.2 (build 20260331)
The pattern strongly suggests the conflict resolution introduced in #8671 (or a subsequent change) is still incorrectly resolving "delete/new" conflicts as "delete" in specific VFS sync scenarios on Windows, particularly when applications create and immediately remove lock files inside synced directories.

Workaround: Downgrade all Windows clients to 4.0.8. Issue does not occur on that version.