[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
No im using nextcloud snap and same issue here so its not AIO |
|
Just in case, I'm using the comunity Docker image. But this is a client issue, so I don't think that matters. |
|
A similiar issue regarding moving image files with virtual file on windows: If I move a number of image files without first downloading them, the moved files will not be synced, I got error messages in the log saying the date is invalid. I have to first open the files one by one so the modified date becomes valid. Marking the folder as "alwayse available" triggered the similar problem as seen by others, the move is not synced to the server. Restarting the client does not solve the problem, I have to move it out of a nextcloud folder and move them back into the destination. (this is reported in bug #6816) |
|
We have the same problem. It's really bad bug, and want it to be fixed. |
|
is this issue is being worked on ? |
|
IO refer to my post above. Seems still to be correct:
|
|
Just spent an hour finding the cause of the problem.. and ended up here.. I would really appreciate a bug-fix-update soon! |
|
I'm glad I found this thread. This drove me nuts for over a week now. I downgraded to the 3.12.6 client and it all works fine now. |
|
I can as well confirm that the initial issue is resolved with release 3.12.6 |
|
Any explanation why this isn't being addressed? |
It looks like it has already been fixed. The fix will come in the next update. |
|
Great news! :) |
|
When will it be? next update. |
|
I've exactly the same problem, very annoying if my customer download the not correctly renamed files. |
|
I do feel that this should be part of the regression test for a new release. Change the name of a file, make sure it's being synced correctly. |
|
Can confirm that both name changes and moving operations work as expected. Thanks @mgallien and @PhilippSchlesinger ! NC 28.0.7 |
|
@Castiontone @mgallien As it is resolved now, this issue could be closed, right? |
|
I also tested it and my problem seems to be fixed. Thanks @mgallien! I propose to let it open for another day or so, since there where several modes of failure for different people. Let them check also if everything works as expected before closing it. |
|
When I press update, I don't get the update from 3.13.0 to 3.13.1, but I guess I'm a but impatient ;) I'm happy to read here that the problem seems to be resolved! |
|
fixed here too |
You can download the latest installer here https://github.com/nextcloud-releases/desktop/releases |
|
Since nobody else reports any additional errors, only that it now works. This issue can be closed. |
|
Fixed indeed (3.13.3). Thank you ! |
and others
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: