Repository navigation
[Bug]: Windows VFS (wincfapi) deletes files copied into the sync folder ("Delete all files?" dialog), folders and in-place created files survive #11044
Description
⚠️ 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
With Windows virtual files (wincfapi) enabled, any file copied into the sync folder from outside is treated as "deleted on the server" and removed locally, instead of being uploaded. The client shows the dialog "Delete all files? A large number of files on the server have been deleted…" with the choices "Restore files to the server" / "Proceed with deletion". Nothing is ever uploaded: the server never receives the files and logs nothing.
What is affected and what is not (same machine, same account, same server, tested on 2026-10-09):
| Action inside a VFS sync folder | Result |
|---|---|
| File created in place (Explorer → New → Text document) | ✅ kept and uploaded |
File copied from outside (from C:\, from Downloads, from a OneDrive folder; old or freshly created file) |
❌ removed locally, "Delete all files?" dialog |
| Folder copied from outside | ✅ folder kept and created on the server — ❌ the files inside it are removed |
| Same operations with a classic sync connection (no VFS) | ✅ everything kept and uploaded |
It happens:
- on a brand-new VFS connection with a new, empty local folder and a fresh
.sync_*.db(so not a corrupted journal); - on a folder of the user's home storage (not external storage) and on external storage (Local) folders alike;
- on two different Windows 11 PCs (two different accounts).
Server-side permissions are fine: PROPFIND returns oc:permissions = RGDNVCK for the home-storage test folder and RMGNVCK for the external-storage root (CK present). An earlier incident on the same client logged "virtual file without db entry" for ~900 copied files before removing them.
Steps to reproduce
- Windows 11, desktop client 34.0.5, add a folder sync connection with virtual files enabled, new empty local folder (e.g.
C:\Nextcloud\test-vfs), remote = a new empty folder in the user's home. - In Explorer, inside the sync folder, create a file with New → Text document: it is uploaded normally.
- Copy (Ctrl+C / Ctrl+V) a few files from
C:\orDownloadsinto the sync folder. - Within seconds the copied files are removed locally and the "Delete all files?" dialog appears. The remote folder stays empty.
- Copy a folder containing files: the folder appears on the server, its files are removed locally.
- Repeat with a connection without virtual files: all files are uploaded.
Expected behavior
Files copied into a VFS sync folder are detected as new local files and uploaded, exactly like files created in place or files in a classic sync folder.
Which files are affected by this bug
Any file copied into a VFS sync folder from outside (tested: CSV, PDF, PNG, TXT).
Which files are affected by this bug
Any file copied into a VFS sync folder from outside (tested: CSV, PDF, PNG, TXT).
Operating system
Windows
Which version of the operating system you are running.
Windows 11 Pro 10.0.26200
Installation method
Official Windows MSI
Nextcloud Server version
35.0.1 (TrueNAS SCALE app, Docker)
Nextcloud Desktop Client version
34.0.5
Did this occur after an update or on a clean installation?
Clean desktop client installation
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
Nothing logged: no PUT request reaches the server for the removed files.Additional info
- Classic sync works with the same account and server: the problem is specific to wincfapi.
promptDeleteAllFiles=trueandmoveToTrash=trueare set; removed files end up in the Windows recycle bin.- Debug archive available on request (not attached publicly because it contains account information).
Activity
itss78-code commentedon Oct 25, 2026
Root cause found, reproduced on client 35.0.0 (Windows 11, virtual files / cfapi).
The client deleted four folders locally right after they were moved into the sync folder. The debug log shows, for each of them:
No request reached the server.
The folders had been moved out of the user's OneDrive folder.
VfsCfApi::statTypeVirtualFile(src/libsync/vfs/cfapi/vfs_cfapi.cpp) marks every directory that carries a cloud reparse tag (IO_REPARSE_TAG_CLOUD*) asItemTypeVirtualDirectory, no matter which sync provider owns it. OneDrive's placeholder directories carry the same tag. Since commit 35ec5b8 "fix(windows): Prevent re-upload of local placeholder directory deleted remotely" (#10576; backported as f60f8d8, first released in 34.0.2), discovery removes such a directory when it has neither a DB record nor a server entry (isStaleVirtualDirectoryin src/libsync/discovery.cpp). A folder moved in from OneDrive matches all three conditions, so it is deleted together with its contents instead of being uploaded.Steps to reproduce: Windows, virtual files enabled, move a folder from a OneDrive folder into the Nextcloud sync folder. The folder disappears within seconds.
Suggested fix: only treat a directory as a stale Nextcloud placeholder when the placeholder actually belongs to this client (for example by checking the placeholder identity from CfGetPlaceholderInfo against our own file id format). Otherwise it should follow the local-new path. At the very least, never wipe a directory that contains hydrated, non-placeholder content. A duplicate upload is recoverable, deleted user data is not.