Sync Pending - Windows 10

[afzl-wtu]

This Sync Pending status is very irritating. You can see folder is uploaded to server but it is still showing me it is pending in status. Also please clean those garbage files with pending status. They keep getting focus. PLease remove .sync_b39e158b5df3.db and other log files in director or do not show pending status.

[azukaar]

#4201

[dirrgang]

While possibly related to #4201, it would appear to be a slightly different manifestation. I have the same issue: Files are synchronised properly (as far as I can tell), but all files are shown as sync pending.

Windows 11, Nextcloud Desktop-Client Version 3.4.2 (Windows). I have uploaded the debug archive.

[dirrgang]

Issue persists with client version 3.4.3

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[dirrgang]

I managed to fix it by removing Nextcloud and all Nextcloud files located in AppData as well as the sync folder.

[pzwahlen]

Hi devs!

Is there anything we can do to help figuring out what is happening here ? I have this problem on new client installations so I am not sure it depends on old files in appdata{local,roaming}.

I am running 3.4.4 on Win10 21H2 against the official docker image for 23.0.3.

By playing with "Always keep on this device" and then "Free up space", some files would go back to the normal "Available when online" (cloud status icon) and some others would go back to "Sync pending". For those, it would be interesting to know if space is actually freed or not.

Happy to help with debug here and "keep up with the great work!"

[pzwahlen]

A quick update to let everyone know that 3.5RC3 doesn't help with this problem.

[pzwahlen]

I think this bug is the same as https://github.com/nextcloud/desktop/issues/4383, except I can see it with many other filetypes. It also seems identical to https://github.com/nextcloud/desktop/issues/3301 which was automatically closed because of no response.

[virtaj]

Having same issue with Windows 11. Desktop client 3.4.4 and Nextcloud 23.0.3 on docker.

[CoYoNq]

Same issue here, but only with files which size is < 5kb and VFS enabled. IE, i can create a file (a simple txt with only some chars on it), get it synced, but when i sent it to server, sync state on file still "pending". It only happends with files less than 5kb size. If i add some bytes to the file, it ends getting the right state! This happends with any kind of file. I was trying to track this error but with no luck (check full logs of server and client, but no errors found) Everything performs great (lots of files syncing with no issue, only this little ones fails) My setup: Self hosted Nextcloud Hub II (23.0.3) server 20 Win 10 clients (with 3.4.4 version) in an exclusive LAN About 270gb of files (with any kind of files)

[pzwahlen]

Now that I read this, I think you are right and this happens on small files. Is there a desktop debug procedure one can follow in order to better understand what is happening ?

[dnwhoop02]

Same issue here, and it definitely only happens with small files. In my case there are about 1,600 files under 5KB that stay in the "waiting to sync" state. These are files that are on the local hard drive, and at some point I told the client to "free up space". The client freed up all of the bigger files, but left these on the hard drive stuck in this state. The client periodically tries to sync the 1,600 files again, which is slightly annoying, but the bigger problem with this is that every time I make real changes to other files, or create new files (triggering a sync), the client tries to sync the 1,600 small files first, then it finally gets to the one or two files that actually needed to be sync'd. I've found that if I right click on these small files and select "Always keep on this device", the status changes to solid green checkmark, then I can right-click them again and clear the checkmark next to "Always keep on this device", and the status changes to green/white checkmark (as it should), and then the sync client will stop worrying about that particular file. I just found out that I can open the Nextcloud folder and type size:tiny in the search box and it'll find all the files under 15K, so I can try the "Always keep..." workaround on all of them...

[pzwahlen]

Hi,

Now that 3.5.0 is out it would be great to tackle this issue. In order to validate and confirm the link with file size, I have done the following.

Wrote a simple Powershell script that writes files with random content. File size is incremented from 0 to 8k in steps of 8 bytes and the file name is the actual content size written in HEX

$outDir="$PSScriptRoot\nc4226";
if (!(Test-Path -path $outDir)) {new-item -path $outDir -itemtype directory}

for ($i=0; $i -le 8192; $i=$i+8 ) {
  $fSize = $i;
  $fName = $i.ToString("X4");
  $fContent = [Byte[]]::new($fSize);
  $rng = [System.Random]::new();
  $rng.NextBytes($fContent);
  [System.IO.File]::WriteAllBytes("$outDir\$fName", $fContent);
}

You can download a zip archive of the output here: https://cloud-dev.lesz.ch/s/BYT4ktYnqKAkXTL

When I drop this folder within the NC folder (with Virtual Filesystem enabled) and wait for the initial sync, the folder appears as locally available, as expected:

All files within the folder are also locally available, as expected:

Now if I "Free up space" on the folder, I can see that the empty file gets the correct status but all larger files get the wrong "sync in progress" status:

I can easily sort the folder by file size and we can see that all files below 4k get the wrong status and all files >4k are showing the correct status:

Also, any sync activity from this point will trigger a resync of all the file <4k in size (except the empty file).

[CoYoNq]

Any news regarding this? New Win client (3.5.1) still showing this bug. I still trying to track this issue, but can't find any relevant info in server or client log. The impact in global performance (all machines in my scenario are VMs, so, resources can be easylly monitoreable) of a continuous trigger to sync this tiny files is really high. NC server and clients are affected by this "load spikes".

[andreaslink-de]

I just want to confirm, I have the exact same problem under Windows 10, running newest Win Client 3.5.1. In my case it is related to all my files <=4 kB and it is very annoying, especially when there is a git or subversion folder included, I had more than 10k files continuously being synced in a loop generating quite some load on the system.

My workaround was now to fully delete the connection, set it up again and do not mark anything with "Always keep on this device". Then I can at least work without always pausing the sync.

Looking very much for a solution.

[pzwahlen]

Dear @camilasan @mgallien @allexzander @matthieugallien

According to the repo history you seem to be the devs making changes to the Windows "vfs" and "cfapi" code and therefore you might want to have a look at this bug which (I think) is affecting the entire userbase (Windows+VFS).

I have created a simple reproducer in the issue thread.

Also, I tried to find places where the code would depend on a 4k buffer/size limit and I could only find those two:

https://github.com/nextcloud/desktop/blob/4efe00fecaf88b587c6bcb75f1af17ba1fa12747/shell_integration/windows/NCUtil/CommunicationSocket.cpp#L25

https://github.com/nextcloud/desktop/blob/8f7646d93fe8eea19ceacccf92045bfd77e0dd87/src/gui/folderwatcher_win.cpp#L61

Could one of them be part of the issue ?

Cheers!

[pzwahlen]

I have just updated my client to 3.5.2 and the problem is still there.

I don't know yet if it will help, but I am attaching 2 debug log files. These where generated by doing a "Free up local space", first on a <4k file (NOT.txt) and then a >4k (OK.txt) file

free_NOK.txt free_OK.txt

I couldn't spot an obvious error/difference but expert eyes are needed here.

[Dremor]

Interesting note that may or may no be related: even the excluded files get a "pending sync" status icon. Disabling VFS give the correct behaviour.

[pzwahlen]

I'm just giving a gentle bump to this issue. Could someone add it to the "clients team" board here: https://github.com/orgs/nextcloud/projects/48

This might give it some additional visibility.

[mgallien]

to be honest, I am working on this but because of poor documentation from Microsoft I am struggling to find the exact wrong API call within the desktop client code but be sure that this is known and not forgotten

[pzwahlen]

Thx @mgallien, knowing that someone knowledgeable is working on this has made my day! I think we all appreciate the hard work here.

Cheers!

[BasicUser22]

Hello, I've got the same problem on about 53000 files. Nextcloud version

client : 3.5.2 server : 24.0.3 Operating system and version

client : windows 10.0.19044 server : Debian 11 Apache : Apache/2.4.54 (Debian) PHP version : PHP 8.1.8 (cli) (built: Jul 11 2022 08:55:24) (NTS)

The issue you are facing : I have to keep some files on my desktop because they can’t be “Free up”

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it : I don’t know actually how to create the problem But, if I take a problematic file and copy it in a new folder, the problem remains In the sync.log file (AppData/Roaming/Nextcloud) :

• the initial copy leaves the following trace => the file is stored on the desktop and synchronized

timestamp duration file instruction dir modtime etag size fileId status errorString http result code other size other modtime X-Request-ID 18:09:22 <file> 8 1 1659990112 5e7d27e78bcf2bd1c22a1ee0999d8adc 1682 00452258oc6lwp0up92s 4 201 0 0 b503a6c9-70ae-4072-9620-80484283c7db

• when I try to free up the space, I’ve got the following trace : [ debug default C:\Users\sysadmin\AppData\Local\Temp\2\windows-10816\client-building\desktop\src\libsync\propagateupload.cpp:300 ] [ OCC::PropagateUploadFileCommon::slotComputeContentChecksum ]: Trying to compute the checksum of the file 2022-08-09 20:09:22:925 [ debug default C:\Users\sysadmin\AppData\Local\Temp\2\windows-10816\client-building\desktop\src\libsync\propagateupload.cpp:301 ] [ OCC::PropagateUploadFileCommon::slotComputeContentChecksum ]: Still trying to understand if this is the local file or the uploaded one

I also notice that the desktop client stops suddenly and repeatedly

[CoYoNq]

Hi! Any news about this one? I was trying to see if this bug was related to #3349 but, after a possible fix released, looks like not. Still happening after the bug fix released by @mgallien to solve #3349. Problem is, syncs continue to try to get the small files in every cycle, and sometimes, depending on the number of files involved, even, crash the client. Please, give this one some priority, it a very annoying bug that affects the whole vfs system. Thanks!!!

[afzl-wtu]

Hi! Any news about this one? I was trying to see if this bug was related to #3349 but, after a possible fix released, looks like not. Still happening after the bug fix released by @mgallien to solve #3349. Problem is, syncs continue to try to get the small files in every cycle, and sometimes, depending on the number of files involved, even, crash the client. Please, give this one some priority, it a very annoying bug that affects the whole vfs system. Thanks!!!

Major issue of free projects. I switched to Onedrive again.

[CoYoNq]

Major issue of free projects. I switched to Onedrive again.

This kind of comments don't collaborate to solve the issue. Devs are working, users try to help reporting issues, collecting/providing info and testing new releases/features. Thats why free projects are great. Be patient, i just want to bump the issue and inform that the suspicious related bug was not related (imho).

[afzl-wtu]

Major issue of free projects. I switched to Onedrive again.

This kind of comments don't collaborate to solve the issue. Devs are working, users try to help reporting issues, collecting/providing info and testing new releases/features. Thats why free projects are great. Be patient, i just want to bump the issue and inform that the suspicious related bug was not related (imho).

No No I am not criticizing NextCloud. I just love next cloud. I just told you developers have not enough time to fix issues of free projects because they do it as their hobby.

[CoYoNq]

Some "new" info: This issue appears when you efectively download the files <5k. If you dont do that (files are in the server but you never download them) issue is not shown (file appears as "cloud" status correctly) First and second files never was download to the client Third one was downloaded and sended back. It sticks in sync state (and every resync, client try to resync it, generating a permanent loop against all files in this state)

[CoYoNq]

bump! Any news? As workaround, I have to switch all stations to a WebDAV connection and remove NC client due to this (the endless sync attempt don't allow to work with other files making system unusable in production) With a standar WebDAV connection (via file explorer), stations works fine. Please mark this issue as critical, at least, in a VFS scenario. Thanks!

[AndyXheli]

Hi all still present in 3.6.0 @mgallien any updates on this?

[yardbro]

Also dealing with this issue on Windows client version 3.6.0. All the files stuck in the "sync pending" status are some type of text file and <5KB in size.