[Bug]: Windows client 3.12.4 and 13.3 does not sync renamed or moved files #6721
Comments
|
Same problem here, nextcloud upgraded to Nextcloud Hub 8 (29.0.0), windows client version 3.13. Modified files are not updated. Going back to version 3.12.3 fixes the problem. |
|
EDIT: Downgrade to 3.12.3 for a fix: https://github.com/nextcloud-releases/desktop/releases/download/v3.12.3/Nextcloud-3.12.3-x64.msi As a comment: This bug is really bad! After downgrading, my clients went nuts about different versions of my keepass file. Fixing manually was not fun, but way worse, if one of the systems would have died, I had lost passwords... IMHO 3.13 and 3.12.4 should be removed for windows until this bug is fixed in a new version. |
|
For me, the issue happens when the file is NOT virtual. Virtual files can't be edited, so I can't test that, but they can be moved. If the file is virtual (it has the cloud icon in Windows Explorer) moving it to a different folder will also move it in the server. The bug only happens if the file is locally available. This issue happens in both 3.13.0 and 3.12.4. |
|
I have tried version 3.12.4 and for me it still has the error. It does not update the files when they change. |
|
This seems to be even more complex. I tried to find out how long it takes for the files to be changed (using 3.12.4). I changed the file on the windows machine and then check the content of the file on a linux system via mounted webdav in a loop to measure roughly seconds. For the first ~8 changes it took between 45 and 80 seconds ... and then it stopped updating completely. So this is really unpredictable and this might be the reason why it works for some people on some version and not for others. I might test different versions to find out which version really did work all the time. Also I can confirm the problem with moving files as described by @diegodan1893 |
|
It is VERY clear when the problem was introduced. 😂 As @diegodan1893 and @ivanes82 said, the last working version is 3.12.3. With 3.12.4$ ./check_nextcloud_delay.sh
Starting to measure Nextcloud delay
Content updated after 37 seconds (random delay was: 9)
Content updated after 57 seconds (random delay was: 3)
Content updated after 50 seconds (random delay was: 9)
Content updated after 53 seconds (random delay was: 7)
Content updated after 51 seconds (random delay was: 9)
Content updated after 53 seconds (random delay was: 8)
Content updated after 51 seconds (random delay was: 9)
Content update took more than 3 minutes, exiting
Starting to measure Nextcloud delay
Content updated after 51 seconds (random delay was: 9)
Content updated after 58 seconds (random delay was: 1)
Content updated after 54 seconds (random delay was: 4)
Content updated after 54 seconds (random delay was: 8)
Content update took more than 3 minutes, exitingWith 3.12.3$ ./check_nextcloud_delay.sh
Starting to measure Nextcloud delay
Content updated after 4 seconds (random delay was: 2)
Content updated after 5 seconds (random delay was: 4)
Content updated after 4 seconds (random delay was: 7)
Content updated after 5 seconds (random delay was: 6)
Content updated after 4 seconds (random delay was: 7)
Content updated after 3 seconds (random delay was: 0)
Content updated after 5 seconds (random delay was: 1)
Content updated after 4 seconds (random delay was: 9)
Content updated after 4 seconds (random delay was: 2)
Content updated after 5 seconds (random delay was: 7)
Content updated after 5 seconds (random delay was: 6)
Content updated after 4 seconds (random delay was: 6)
Content updated after 3 seconds (random delay was: 0)
Content updated after 4 seconds (random delay was: 8)
Content updated after 4 seconds (random delay was: 2)
Content updated after 3 seconds (random delay was: 8)
Content updated after 3 seconds (random delay was: 5)
Content updated after 5 seconds (random delay was: 5)
Content updated after 4 seconds (random delay was: 2)
Content updated after 3 seconds (random delay was: 1)
Content updated after 5 seconds (random delay was: 6)
Content updated after 4 seconds (random delay was: 9)
Content updated after 4 seconds (random delay was: 8)
Content updated after 5 seconds (random delay was: 9)
Content updated after 3 seconds (random delay was: 0)
Content updated after 57 seconds (random delay was: 0)
Content updated after 4 seconds (random delay was: 1)
Content updated after 3 seconds (random delay was: 4)
Content updated after 3 seconds (random delay was: 7)
Content updated after 4 seconds (random delay was: 8)
Content updated after 56 seconds (random delay was: 0)
Content updated after 4 seconds (random delay was: 1)
Content updated after 3 seconds (random delay was: 4)
Content updated after 3 seconds (random delay was: 2)
Content updated after 5 seconds (random delay was: 4)
Content updated after 3 seconds (random delay was: 6)
Content updated after 6 seconds (random delay was: 3)
Content updated after 3 seconds (random delay was: 4)
Content updated after 3 seconds (random delay was: 2)
Content updated after 5 seconds (random delay was: 5)
Content updated after 3 seconds (random delay was: 0)
Content updated after 5 seconds (random delay was: 2)
Content updated after 4 seconds (random delay was: 4)
Content updated after 4 seconds (random delay was: 5)
Content updated after 3 seconds (random delay was: 0)
Content updated after 5 seconds (random delay was: 5)
Content updated after 4 seconds (random delay was: 8)
Content updated after 5 seconds (random delay was: 1)
Content updated after 4 seconds (random delay was: 8)
Content updated after 3 seconds (random delay was: 3)
Content updated after 37 seconds (random delay was: 0)
Content updated after 3 seconds (random delay was: 6)
Content updated after 5 seconds (random delay was: 2)
Content updated after 4 seconds (random delay was: 4)
Content updated after 3 seconds (random delay was: 6)
# stopped it manually |
oxivanisher
changed the title
oxivanisher
changed the title
oxivanisher
changed the title
|
I can confirm. Had the same problem with 3.13.0 and now after a downgrade to 3.12.3 it works perfectly fine. |
|
My wife and I have identical win10 laptops except mine way more memory, and Win 10 Home version. Hers is Win10 Pro version. Both Windows client 13.3. Hers has no problem. Mine, when I rename a file or move it, the syncing icon is perpetual, the file is effectively disconnected from nextcloud which thinks sync was successful. Force sync does nothing and the same symptoms continue. Is my windows Home version an issue by not setting a flag allowing outside control, and the 12.4 and 13.3 client uses this flag? I am terrified to degrade to 12.3 based on oxivanisher's experience. My symptoms are consistent enough that I will stick with workaround until this is figured out. |
I didn't have any issues downgrading. If you only experienced issues when moving or renaming files, it should be fine. Also, I'm in Windows 10 Pro, so I don't think is a Home version issue. |
|
@JeremyJava I also think you should be ok downgrading your clients. My problems with the keepass files was because the clients did not sync and the files went "out of sync". Downgrading only showed the problem, but it already existed because of the new client. |
|
I can confirm the issue with 3.12.4 and that downgrading to 3.12.3 resolves the issue. |
|
I am using V3.13.0 + NC 28.0.3 and the problem persists. I can rename VFS files with no issues but if I try to rename a synchronized file, the client does not rename it on the server and all subsequent changes get stuck. @mgallien - can you please assist? I do have a bunch of users complaining of the same issue. |
|
I think I've experienced this while renaming files. Everything I rename ends up as pending and does not sync. This was a major issue yesterday when I was trying to batch rename a bunch of pictures, but then they didn't sync! I'm using Nextcloud 3.13.0.20240423 on Windows 10 22H2. EDIT: Also confirming that downgrade to 3.12.3 resolves the sync issues. |
|
Yes the problem seems to be related to renaming and moving. A new file in the folder syncs ok. |
|
Edits to a textfile do not reach the server although sync client says I changed it. Going to settings and clicking "Force sync now" helps as a workaround without needing to restart sync client. |
Did anyone find that out already? |
I have tested 3.12.5 today and it has the same problem. The latest version not presenting this issue is 3.12.3 |
|
I am having the same issue here using the Desktop Client V3.13.0 + NC 28.0.3 My logs after trying to rename a file: |
|
Confirm that bug persists in every iteration of the desktop client after 3.12.3 NC 28.0.5 |
|
So this already solved earlier. And reintroduced? https://help.nextcloud.com/t/nc-client-3-12-0-not-recognizing-file-renaming-in-windows/183635 |
|
@oxivanisher can you rename this isue to "Windows client 3.12.4 and 13.3 does not sync renamed or moved files"? Since now we know that moving/renaming the file is what triggers the bug. Otherwise the developers have to read the comments to know what the bug is about, maybe that's the reason this is still in "needs triage". |
oxivanisher
changed the title
Sure and done. Let's hope somebody reads this ... its a really bad bug! |
Bug description
The Nextcloud Client does not sync changed files on Windows.
All Windows clients I use, use the Virtual Filesystem. The server does not produce a log entry during this, so I think its only client related. Also on a Linux client with 3.13, the sync works without a problem. Strangely, the client (sometimes?) shows that the file has been changed, but the upload to the server does not happen.
I was able to test it with a 3.12.3 windows client (also with VFS) which works as expected. After upgrading this client to 3.13, it also stopped syncing instantly. The sync can be forced by exiting and restarting the client.
Steps to reproduce
Expected behavior
The file should be synced automatically after being changed.
Which files are affected by this bug
test.txt
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Package
Appimage
Nextcloud Server version
28.0.5
Nextcloud Desktop Client version
3.13 and 3.12.4
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
Additional info
The debug archive was way to big to upload here. Also I am not that keen on uploading a directory listing of all my files to the internet... This is the sqlite entry of the
tmp/test.txtfile from the .sync_*.db file:INSERT INTO "main"."metadata" ("phash", "pathlen", "path", "inode", "uid", "gid", "mode", "modtime", "type", "md5", "fileid", "remotePerm", "filesize", "ignoredChildrenRemote", "contentChecksum", "contentChecksumTypeId", "e2eMangledName", "isE2eEncrypted", "isShared", "lastShareStateFetchedTimestmap", "sharedByMe", "lock", "lockType", "lockOwnerDisplayName", "lockOwnerId", "lockOwnerEditor", "lockTime", "lockTimeout") VALUES ('-1217135354298682854', '12', 'tmp/test.txt', '1130930', '0', '0', '0', '1714567689', '0', '02068fe69d062d487bf06261d814f2c4', '0527984351b4b9d916170', 'WDNVR', '7', '0', '843c14c6c9259eb62ab88af596c209144682a7ca', '1', '', '0', '0', '1714568128430', '0', '0', '0', '', '', '', '0', '0');
These are the logs from the client from the last hour of testing:
20240501_1444_nextcloud.log.0.gz
20240501_1443_nextcloud.log.2.gz
20240501_1443_nextcloud.log.1.gz
20240501_1443_nextcloud.log.0.gz
20240501_1450_nextcloud.log.0.gz
20240501_1445_nextcloud.log.0.gz
The text was updated successfully, but these errors were encountered: