Desktop: Bulk sync of encrypted files is stuck

[Linuxfabrik]

Expected behaviour

All encrypted files should be synced.

Actual behaviour

The first file is correctly synced, but then the sync is stuck.
The encrypted folder is shown as 0 B.
Restarting the sync or the nextcloud client does not help, it causes one more file to sync and then it is stuck again.

Steps to reproduce

1. Create a new empty folder.
2. Encrypt the folder.
3. Quickly generate 100 files in that folder.
   for i in {1..100}; do dd if=/dev/urandom of=sample_$i bs=100M count=1; done

(Expected behavior can be produced using by adding a timeout, eg for i in {1..100}; do dd if=/dev/urandom of=sample_$i bs=100M count=1; sleep 30; done)

Client configuration

Client version:
2.5.2git

Operating system:
Fedora Workstation 29

OS language:
English US

Qt version used by client package (Linux only, see also Settings dialog):
5.11.0

Client package (From Nextcloud or distro) (Linux only):
Nextcloud-2.5.2-x86_64.AppImage

Installation path of client:

Server configuration

Operating system:
CentOS 7

Web server:
Apache 2.4.6

Database:
MariaDB 10.2.24

PHP version:
7.2.18

Nextcloud version:
15.0.7

Storage backend (external storage):

Logs

1. Client logfile:
   https://gist.github.com/Linuxfabrik/fe12ac5d2358d0f1ae4e0c4002594708

2. Web server error log:
   Nothing related.

3. Server logfile: nextcloud log (data/nextcloud.log):
   Nothing related.

Possibly related issue

https://github.com/nextcloud/desktop/issues/890
https://github.com/nextcloud/desktop/issues/1168

[adimol]

I have the same issue, see https://github.com/nextcloud/desktop/issues/890#issuecomment-718971738 .
E2ee is unusable...

[er-vin]

OK, can't reproduce. Can I have debug logs of a sync which gets stuck please? Might be a case I'm not hitting for some reason.

[er-vin]

Since I got asked for how to produce those debug logs, here is my recipe:
1) stop the client
2) from the command line launch the client passing the following extra parameters: --logdebug --logfile ~/nextcloud-desktop.log (assuming linux here, obviously change the path depending on your platform)
3) wait for a failing sync, give it time to get completely stuck and so on
4) quit the client

Now you should have a debug log, this is the one needed to try to debug such things. Be aware that it's very chatty and obviously gives a lot of information about your files. So either you edit out the information you don't want to leak (which means we have obviously less information we can deal with) or you use a private file drop I setup for such cases: https://cloud.nextcloud.com/s/7ZSqepBdwCgwnkA

If you use the filedrop, please make sure to give a proper name to the file so that we can figure out what we're dealing with. It's useful if that at least contains your github user name and the issue number.