Well, I celebrated prematurely. It still has issue after system reboot.
By examining the debug log generated by Desktop Client, I notice the ones that got endless sync has below pattern:
2022-10-20 18:48:47:734 [ info sync.discovery C:\Users\sysadmin\AppData\Local\Temp\2\windows-11938\client-building\desktop\src\libsync\discovery.cpp:350 ]: Processing "公开课/情绪的表达与调节/情绪的表达与调节20190517/情绪的表达与调节.pptx" | (db/local/remote) | valid: false/true/true | mtime: 0/1558067438/1558067437 | size: 0/101022184/101022184 | etag: ""//"3d35a295118b7f7fdecc73c3d8b94520" | checksum: ""//"" | perm: ""//"WDNVR" | fileid: ""//"00006706ocf2vyrcnxmu" | inode: 0/178789/ | type: CSyncEnums::ItemTypeSkip/CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeFile | e2ee: false/false | e2eeMangledName: ""/"" | file lock: not locked//not locked
More precisely, the error pattern is (db/local/remote) | valid: false/true/true | mtime: 0/1558067438/1558067437 | size: 0/101022184/101022184.
I guess it means for some reason, the file doesn’t have corresponding mtime and size in database.
Not sure how these files got into this limbo status. My best guess is a bad client like this?
Anyway, due to my lack of knowledge of SQL, I ended up:
- Stop local Nextcloud Desktop client
- Move the files with above mentioned pattern to another local folder
- Delete the files using Nextcloud Web from the server.
- Run
sudo -u www-data php /var/www/nextcloud/occ files:scan --allto ensure the file and database integrity. - Re-upload the backup files.
Though it consumed a bit more bandwidth, it finally put an end to the problem.
Hope my experience can help.