Desktop: Desktop client 2.5.0 won't sync files correctly

[carlfriedrich]

I upgraded my Nextcloud desktop client to the new 2.5.0 release today, on my Windows 8.1 desktop as well as on my Windows 10 tablet. My existing sync connections have been retained, but they are not working correctly anymore: Only files in the root folder are synced correctly. Files in subfolders are not synced.
Furthermore the client does not sync any files when I add a new sync connection. The subfolders are synced, though, but without any file contents.
All this used to work with the previous client version 2.3.3.
I am running Nextcloud server 14.0.3.0 on a hosted webspace.

Expected behaviour

The client should sync all files from the server.

Actual behaviour

The client syncs folders only, but without any file contents. For each file the activity log states "The file [...] could not be downloaded completely". In large folders I sometimes get "GOAWAY received, cannot start a request".

I tried to reduce this to a minimal example and found out that syncing works correctly if there aren't any subfolders at all. As soon as one subfolder exists, syncing files does not work anymore on new connections. So:

Steps to reproduce

1. Create a new sync connection in the client
2. Choose an empty local folder
3. Choose an existing non-empty remote folder with at least one subfolder, e.g. with the following structure:

• file.txt
• subfolder
  
  
  
  • anotherfile.txt
  
  

1. Wait for sync and see it fail for all files

Client configuration

Client version:
2.5.0

Operating system:
Windows 8.1 / Windows 10

OS language:
German

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

Client package (From Nextcloud or distro) (Linux only):

Installation path of client:
Default path

Server configuration

Operating system:

Web server:

Database:
mysql 5.7.24

PHP version:
7.2.12

Nextcloud version:
14.0.3.0

Storage backend (external storage):

Logs

1. Client logfile: Output of nextcloud --logwindow or nextcloud --logfile log.txt
   https://gist.github.com/carlfriedrich/babe52f847ce3c5a85b2dbbd8a5efe7f

2. Web server error log:
   no access

3. Server logfile: nextcloud log (data/nextcloud.log):
   Nothing relevant in there

[Iolaum]

I also experience a similar problem.

Expected behaviour

Client should sync files properly and not crash.

Actual behaviour

Files do not sync properly, for example moving a file causes the server to delete and re-download it instead of moving it (as I see through activity). Client has crashed a lot of times recently. I use Ubuntu MATE 18.04 and I have send error reports at least 4 times this week.

Steps to reproduce

1. Start my laptop.
2. Move or alter some files that are synced.
3. Check activity logs to see what happened.

Client configuration

Client version:

$ apt policy nextcloud-client
nextcloud-client:
  Installed: 2.5.0-20181111.015125~bionic1
  Candidate: 2.5.0-20181111.015125~bionic1
  Version table:
 *** 2.5.0-20181111.015125~bionic1 500
        500 http://ppa.launchpad.net/nextcloud-devs/client/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

Operating system:

Ubuntu MATE 18.04:

$ uname -a
Linux shade 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

OS language:

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

Client package (From Nextcloud or distro) (Linux only):

Installed from the ppa provided by the nextcloud team (http://ppa.launchpad.net/nextcloud-devs/client/ubuntu )

Installation path of client:

$ which nextcloud
/usr/bin/nextcloud

Server configuration

NextCloudBox running on raspberry pi 2 with the updated NextCloudPi.

Operating system:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.6 (stretch)
Release:    9.6
Codename:   stretch

Web server:

$ apt policy apache2
apache2:
  Installed: 2.4.25-3+deb9u6
  Candidate: 2.4.25-3+deb9u6
  Version table:
 *** 2.4.25-3+deb9u6 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status

Database:

$ apt policy mariadb-server
mariadb-server:
  Installed: 10.1.37-0+deb9u1
  Candidate: 10.1.37-0+deb9u1
  Version table:
 *** 10.1.37-0+deb9u1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status

PHP version:

$ php --version
PHP 7.2.12-1+0~20181112102304.11+stretch~1.gbp55f215 (cli) (built: Nov 12 2018 10:23:04) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.12-1+0~20181112102304.11+stretch~1.gbp55f215, Copyright (c) 1999-2018, by Zend Technologies

Nextcloud version: 14.0.3.0

Storage backend (external storage):

1 Tb external HDD (original provided by NextCloudBox)

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.

Template for output < 10 lines

1. Client logfile: Output of nextcloud --logwindow or nextcloud --logfile log.txt
   (On Windows using cmd.exe, you might need to first cd into the Nextcloud directory)
   (See also https://docs.nextcloud.com/desktop/2.3/troubleshooting.html#log-files)

2. Web server error log:

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

[JanSvoboda]

Hello,

I have encountered the same issue. What helped me was to disable e2e encryption application on nextcloud server. It seems that calling GetFolderEncryptStatus and the response to it with 404 distrupts the synchronization of files

[carlfriedrich]

I can confirm that deactivating the e2e app on my server made the client 2.5.0 correctly start syncing files again.
This can serve as a workaround for now, but since I would like to use e2e, the issue should be fixed.

[Ralayax]

Same issue, same solution for me.

[Iolaum]

I do not have neither server-side nor client side encryption but I am still getting sync problems. Often the client appears to not do anything. The solution is to close the program and re-start it. That helps the desktop client get in a state where it starts syncing files again. Still this is far from ideal and a regression compared to 2.3.3

[bjoernv]

For me syncing itself works, but in 2.5.0 it is annoying. In my Nextcloud setup I excluded some folders (e.g. build directories for a software project) and Nextcloud 2.5.0 tells me every time after a sync run, that there are unsolved conflicts. The "conflicts" are in fact excluded files and directories. The "conflicts" are reported as desktop notifications even if server notifications are disabled. Also CPU usage is high and the client crashes after some hours. I do not have client or server side encryption enabled. It is an regression compared to 2.3.3.

[Iolaum]

I 've also gotten conflicts that I resolved by either waiting until the client+server spoke again and resolved them or by restarting the client.

[tanghus]

I have somewhat of the same problem.
After updating the client, it disconnects shortly after.
I get a lot of failed logins in the server log

In the client log, it repeats the following for each folder:

[OCC::FolderMan::scheduleFolder     Folder is not ready to sync, not scheduled!
[OCC::ownCloudGui::slotSyncStateChange  Sync state changed for folder  "https://cloud.example.com/remote.php/webdav/Notes" :  "Not yet Started"
[OCC::ConfigFile::setupDefaultExcludeFilePaths  Adding user defined ignore list to csync: "/home/tol/.config/Nextcloud/sync-exclude.lst"
[OCC::FolderMan::addFolderInternal  Adding folder to Folder Map  OCC::Folder(0x55b19875a610) "5"
[OCC::FolderMan::scheduleFolder     Schedule folder  "5"  to sync!
[OCC::FolderMan::scheduleFolder     Folder is not ready to sync, not scheduled!
[OCC::ownCloudGui::slotSyncStateChange  Sync state changed for folder  "https://cloud.example.com/remote.php/webdav/Photos" :  "Not yet Started"
[OCC::ConfigFile::setupDefaultExcludeFilePaths  Adding user defined ignore list to csync: "/home/tol/.config/Nextcloud/sync-exclude.lst"
[OCC::FolderMan::addFolderInternal  Adding folder to Folder Map  OCC::Folder(0x55b198781270) "6"
[OCC::FolderMan::scheduleFolder     Schedule folder  "6"  to sync!
[OCC::FolderMan::scheduleFolder     Folder is not ready to sync, not scheduled!
[OCC::ownCloudGui::slotSyncStateChange  Sync state changed for folder  "https://cloud.example.com/remote.php/webdav/tanghus_dot_net" :  "Not yet Started"
[OCC::ConfigFile::setupDefaultExcludeFilePaths  Adding user defined ignore list to csync: "/home/tol/.config/Nextcloud/sync-exclude.lst"
[OCC::FolderMan::addFolderInternal  Adding folder to Folder Map  OCC::Folder(0x55b198781ec0) "7"
[OCC::FolderMan::scheduleFolder     Schedule folder  "7"  to sync!
[OCC::FolderMan::scheduleFolder     Folder is not ready to sync, not scheduled!
[OCC::ownCloudGui::slotSyncStateChange  Sync state changed for folder  "https://cloud.example.com/remote.php/webdav/InstantUpload" :  "Not yet Started"
[OCC::ConfigFile::setupDefaultExcludeFilePaths  Adding user defined ignore list to csync: "/home/tol/.config/Nextcloud/sync-exclude.lst"
[OCC::FolderMan::addFolderInternal  Adding folder to Folder Map  OCC::Folder(0x55b1987873d0) "8"
[OCC::FolderMan::scheduleFolder     Schedule folder  "8"  to sync!
[OCC::FolderMan::scheduleFolder     Folder is not ready to sync, not scheduled!
[OCC::ownCloudGui::slotSyncStateChange  Sync state changed for folder  "https://cloud.example.com/remote.php/webdav/Uploads" :  "Not yet Started"
[OCC::SyncJournalDb::checkConnect   sqlite3 version "3.22.0"

It started to work again when I removed the account and added the sync connection one by one and let them sync one at a time.

After restarting the client it failed again.

[tanghus]

Client log: https://gist.github.com/tanghus/ba05b925b5c69b6ac0c04ec679d8dc1f

[tanghus]

It could be related to #771

[mduller]

Same here - only restarting the client (2.5.1 on Windows 10 1809) makes it pick up files in subfolders. I don't use e2e encryption.

_Edit: add Windows version_

[stratacast]

I couldn't get sync to work until I disabled e2e server side also. I was continually getting the GOAWAY errors as mentioned earlier.

[daftmilk]

Same problem on Mac: Moving a folder with subfolders into Nextcloud or just renaming a hierarchical folder structure only syncs folders at the first level but not on the sublevel. I can work around the issue by removing the subfolders, wait for a few seconds and then drop them back in. However I need to repeat this for the subfolders within the subfolders and so on. Looks like somebody just forgot to put the recursive flag into the process that monitors changes. Something to the extend of forgetting to call ls instead of calling ls -R. Feels like it could be a really easy fix…

[Iolaum]

@daftmilk Another solution after you move a folder with subfolders and only syncs the top level folder is to close/quit the client and re-open it. I learnt that neat trick because my client crashes so often that I noticed it synced properly after I restarted it. After it re-opens it will find and sync what it missed the first time.

[csharpner]

Same problem here. 2 desktops, both experiencing root folders sync the files and create the subfolders, but nothing in the subfolders gets synced, not even folders inside the subfolders.

[Peac]

Same problem here on Ubuntu 18.04 and client version 2.5.1.
Quite annoying. Restarting the client does not help.
I'm not using e2e or server side encryption.

[mduller]

Pausing synchronization before adding the folder structure and then resuming synchronization also works around the problem (Client 2.5.1 on Windows 10).
Edit: one detail that may be relevant: I copied the folder structure (from a mounted network share to the local folder set up for sync) instead of moving it!

[Iolaum]

I 'm still having problems with the nextcloud client. I am basically checking the activity tab, that has also re-gressed UI wise from the 2.3.3 version, to make sure that files I changed have been updated on the server. I often find myself pausing and resuming sync or downright closing and restarting the client so that it picks up my changes.

System information:

$ apt policy nextcloud-client
nextcloud-client:
  Installed: 2.5.1-20181204.111806~bionic1
  Candidate: 2.5.1-20181204.111806~bionic1
  Version table:
 *** 2.5.1-20181204.111806~bionic1 500
        500 http://ppa.launchpad.net/nextcloud-devs/client/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

[R8s6]

As of 2019 Feb 07, I can confirm that I still have this error. Server running on ubuntu server 18.04.01 with nextcloud snap, and client version 2.5.1 running on Arch. I don't have server or client encryption. Only folders are synced but no files are synced. Only restarting the client solves the issue temporarily.

[alberto464]

I have the same problem, when I load multiple files the subfolders are not synchronized. Has anyone found the solution?

[chaos-prevails]

Server: 15.0.4, php 7.0 (ubuntu 16.04 server install)
Client: 2.5.1 same problem experiences on linux 18.04 ubuntu desktop and windows (10).

I second this problem as mentioned in #969. Moving or renaming folders deletes them on the server, and only recreates them with a restart of the nextcloud client (v 2.5.1). This problem is not happening with 2.3.3.1. This causes massive troubles in sync/resync/trash if staff is renaming a shallow folder.

This is a major problem, as it is non-trivial to change/downgrade all clients. Hope this can be solved on the server.

[chaos-prevails]

Dear Nextcloud,

is there anything more you would need to work on this bug? #969 includes the sync log, and an extract of the nextcloud-client with logging enabled. It seems #1000 is about the same bug.

So there is evidence that this is a problem for multiple users. And it is a grave problem, because it involves data loss.

[csharpner]

Nextcloud is unusable until this critical bug is fixed.

[woprandi]

I have an instance of Nextcloud to test but I quickly discovered issues with the files sync. A the moment it cannot be massively deployed :/

[meklon]

I confirm the bug.
Nextcloud client is unusable. Connection timeout

meklon@meklon-desktop:~$ apt policy nextcloud-client
nextcloud-client:
  Установлен: 2.5.2-20190319.015224~bionic1
  Кандидат:   2.5.2-20190319.015224~bionic1
  Таблица версий:
 *** 2.5.2-20190319.015224~bionic1 500
        500 http://ppa.launchpad.net/nextcloud-devs/client/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

[gianks]

Hi i'm testing Nextcloud and my experience so far is:

• New folders, expecially when moved rather than created, are ignored or created empty.
• Files are syncronized up to a certain point until no new changes are transmitted to the server.

No errors reported. e2e has been disabled already.
The only solution found so far is to close and start again the client but this sadly makes the software highly unreliable since it reports to sync correctly while it is not.

Version 2.5.2git (build 20190319)

[daftmilk]

Hey guys, this bug is open since November. Can we escalate this? What can we do to help?
It really is no solution to quit the client and reopen.
This leads to data-loss in some situations, so it is pretty critical.

[TechupBusiness]

I'm having the same issues. I will not report a new issue but really hope this will get fixed (Ubuntu 18.04). Sync is very unreliable. If this will not get fixed soon, I need to get back to Dropbox which has the most reliable sync I know... Unfortunately NextCloud is not focusing on the core business, instead it's adding new features that are useless if you can't use the basic functionality...

[R8s6]

I used to have the same issue when I used LAN IP and a self-signed certificate for the nextcloud server. After I have properly set up Let's Encrypt cert I stopped having the issue. Of course, at that time, I was also playing with many other configs, so I'm not exactly sure which "fixed" it for me.

Does someone with a valid domain and certificate from a CA (i.e. NOT a self-signed certificate) still experience the same issue? If so, please ignore my observation above.

[Iolaum]

@R8s6 Yes, I use a let's encrypt certificate on my NextCloud instance (running on a raspberry pi through nextcloudpi) and I still experience issues. I 've made it a habit to check sync history to make sure files have synced. If needed I close and re-open the client to force it to pick up changes.

[csharpner]

It's now MAY and this critical bug is still an issue? This is what we in the software industry call a "production level, high priority bug". That means all other work must stop until this data loss bug is fixed. It's absolutely critical that production level bugs are identified quickly and prioritized to the top of the work queue.

[AaronADev]

I agree with @csharpner, this is absolutely a critical issue. I just had to instruct all the developers on my team to remove their connections on the NextCloud Desktop Client for Windows 10. When folders are moved to a different location on the actual Desktop computer, it actually deletes the files inside the folder and only the folder remains on the server-side. We actually just lost quite a bit of mission-critical data not realizing it was dumping our actual project folder contents into the trash on the NextCloud server. I am working on reverting everyone back to 2.3.3, which is the last version I know of that synced properly. If anyone can provide some feedback on this or lead us in the right direction it would be greatly appreciated. We'll help where we can.

[carlfriedrich]

Thank you very much everybody for sharing your experiences. When I opened this issue in November 2018, the client 2.5.0 had just been released. I spent quite a few hours on researching how to reproduce the error with a minimal example, hoping that this makes a fix more easy for the developers.

As it seems, however, none of the developers actually looks at the issues here on GitHub (as stated by @jospoortvliet in the probably related issue #1000). In fact there is obviously only one single developer for the desktop client at the moment (which is @camilasan, according to the commit history), while Nextcloud is looking for reinforcement (as seen on https://nextcloud.com/jobs/).

So this might at least explain why nothing has happened here for half a year.

However, to push things forward: if any of the linked persons reads this, is there any ongoing research or development concerning this issue? Is there anything we users can do to help analyzing or resolving it?

[kleinph]

According to the other similar (when not same) issue #1000 it is known and they are working on it.

Unfortunately the discussion there is locked to contributors only because of "being too heated".

It is very sad that only one developer is actually working on Nextcloud client, but some short response like "We know, we are on it" or at least "We will investigate" would have been nice (for both issues).

[camilasan]

I am aware of all Github issues that arrive at my inbox. I read all the angry comments. What do you want me to say? I have priorities and I am only one person that is also looking for someone to help me and I also have to take holidays. In other issues we already explained about our priorities and guess what people get angry at that too. Because it is free software and there is a company backing the project it doesn't mean we will jump when you say jump. There is the drive, there is end to end encryption, there is server-client parity, there are customers. So please, don't talk about the project like we leave you here without answers because we want it. That is actually hurtful. We are looking into solving everything. But is has to be one thing at the time.

[Ralayax]

@camilasan I think that most people here aren't blaming you personally, though some comments have of course shown some exasperation from their poster.

I understand that the situation you're in is less than ideal, being the only dev on the desktop repo, and as anyone you certainly deserve holidays and not having more responsibilities than one person can bare.

What can we do to help you debug this issue ? I hope we can at least help a bit to alleviate the pressure you must be under.

On a side note I believe that 2.5.x shouldn't be the recommended version as long as this bug isn't fixed, as we are speaking of potentially very costly data losses. Maybe nextcloud.com should link to 2.3.x instead ?

[misch7]

@Ralayax I wouldn't recommend to link to 2.3.x since it includes outdated OpenSSL libraries and there is alsos in issue in synchronizing with newer server versions.
Using Nextcloud Server version 15.0.5 I had several users running the last version 2.3.3.1 client (for it's 32-bit support) facing infinetely sync loops. Every time the sync was complete, it started all over again, raising the server traffic and draining the batteries of the users tablet PC's.
(And without any warning showing up in the client of course.)

That was the main reason for me to actually build the 2.5.2 client for 32-bit ( see #840 ).

@camilasan I'd like to help you with this issue. I will make myself more familiar with the code and try to reproduce the bug. Just to avoid duplicate work: Did you find the time to look at this at code level / have any clue yet?

[jospoortvliet]

@Ralayax on the website note. That would be possible, but in my mind that would need three things:

• the bug is really serious (in terms of you are losing data, without recovery or easy work-around) and happens all the time. To be honest, while yes, I can reproduce this and yes, this is something that happens, it seems to me quite uncommon, and it doesn't lead to data loss (the files aren't synced NOW, but will be eventually) and there's a work-around (restart your client). Not saying it is FUN, and it actually hit me yesterday in normal use - but it is usually not a huge deal.
• the bug is not present in 2.3.3 (do we know that, did anyone try that yet?)
• we won't be able to fix this quickly - as in, if the next 2.5.x fixes this in a a week or two, I woiuldn't change the website. Of course, this is related to the first point: the more serious it is, the faster it has to be fixed one way or another.

I would consider it, for sure - but I'm really not convinced this is a problem that happens often enough that users should use the old version of the client. Keep in mind that, while it has this issue, the new client also does a lot of things better than 2.3.x did...

[AaronADev]

@Ralayax Howdy. I can confirm that the bug does not exist in version 2.3.3. I switched one developer machine at a time, and all are syncing as expected with no loss or unintentional deletion of files.

So, at this point, everyone on my team has switched to version 2.3.3 with no issues so far. I feel pretty confident that the bug occurred in release 2.5.0+.

Thanks for everyone's input.

[carlfriedrich]

@camilasan Thank you for your reply. I think this helps everybody understanding why this issue is open for so long. I wasn't aware until two days ago that you are the only one working on the desktop client, and I guess no one in this thread was.

@misch7 Thanks a lot for your initiative. If I can assist you with reproducing or testing, let me know.

@jospoortvliet I can also confirm that the bug does not exist in 2.3.3. When I examined it in the first place, I tried the repdroduction steps in the issue description above in both versions. Until now I am still using version 2.3.3 without any issues.
And for myself I can say: If I had stumbled upon this issue when I evaluated cloud storage systems (i.e. if I evaluated Nextcloud right now), I would have decided for Seafile or something else. Would have been a deal breaker for me. So yes, I would strongly consider making 2.3.3 the default, as long as this is not fixed.

[camilasan]

From the first description " Only files in the root folder are synced correctly. Files in subfolders are not synced." Could you try the latest daily build? Because #1000 is solved.
https://download.nextcloud.com/desktop/daily/Linux/Nextcloud-2.5.3.20190513-daily-x86_64.AppImage
Thanks.

[carlfriedrich]

@camilasan Thank you very much for your message. I tried my scenario as described in the issue description with this build:
https://download.nextcloud.com/desktop/daily/Windows/Nextcloud-2.5.3.5428-daily-20190516.exe

Unfortunately, the issue is not fixed. It behaves slightly different than in 2.5.0, though: when I create a new sync connection using the folders and files described in the issue description, the file in the top folder (file.txt) is synced, the file in my subfolder (anotherfile.txt) is not. The sync stays in progress ("Sync is running..." on the tray icon), showing "0 second(s) left, 13 B of 25 B, file 2 of 3" in the GUI and then nothing happens.

When I pause the sync and restart it again or restart the client completely, the sync GUI shows "0 second(s) left, 0 B of 12 B, file 0 of 1" and nothing happens again.

Please note what @JanSvoboda already found out in an earlier comment:

I have encountered the same issue. What helped me was to disable e2e encryption application on nextcloud server. It seems that calling GetFolderEncryptStatus and the response to it with 404 distrupts the synchronization of files

@jospoortvliet I still consider this bug serious. Restarting the client does not serve as a workaround in my case. The file simply never gets synced, my client stays in syncing mode all the time. When I add another file locally, it is never uploaded, regardless of how often I restart the client.

[AaronADev]

@carlfriedrich I have e2e encryption disabled completely on two of my servers and the issue was still there, so I am not sure that it is directly linked to e2e encryption at all. I observed issues on both. Just noting on what @JanSvoboda had written.

[gianks]

Hi, just noticed that nextcloud client on Android doesn't do anything if
you try to load a file via share intent.
No errors that i can see are reported, something appears on the screen for
a fraction of a second but after many attemps i can't upload a picture to
my account.

Is anyone else having the same issue?

[gianks]

Looking in the pending uploads all the share and manual upload attempts are failing with "connection error" even if i click retry. Restarting the application didn't help.
No errors in data/nextcloud.log.

In "activity" nothing about these pending uploads, last activity reported is from yesterday!

EDIT: after multiple attempts seems that i can just upload files smaller than 1 MB.

[riggs498]

I just wanted to confirm also that 2.5.0+ is no go here. I have had to fall back to 2.3.3. No sync issues at all now.

I noticed a few things with 2.5.0+. It always has to do a full sync every time. It also will resend all the files even though 2.3.3 has already successfully upload and checked them. Other times, it undeletes files that have been deleted for a long time. I have no idea where it is pulling it from. Then it will conflict all my hidden files and then have conflicts with files that 2.3.3. has no issue with. 2.5.0+ also locked the server up for a time. I have to restart the server. Once I finally figured out that the desktop client was causing the issue. Everything was right again with 2.3.3.

If you need anything else please let me know.

Thanks,

Ryan

[guzzisti]

Referring to #1000 and this milestone this is fixed in client version 2.5.3.

[carlfriedrich]

@guzzisti #1000 is indeed fixed, but this issue still exists. See my test with nightly build a few posts above.

[Iolaum]

The desktop client is still syncing files incorrectly.

I recently re-formatted my laptop, after adding another SSD, and copied my data back. When I tried to re-establish sync connection I found all kinds of weird problems and errors. One error related to this bug is the following.

Initially the client gives multiple (around 1% of files) errors of this kind:
The file could not be downloaded completely.
/path/to/file/filename

To investigate I go at the file location and check for information on the file, in our example AA030 GitLab.txt:

$ ls -la | grep GitLa
     59 Jun 14 21:47 AA030 GitLab.txt
     59 Jun 16 08:28 .AA030 GitLab.txt.~7daada06
$ md5sum AA030\ GitLab.txt 
054bf21d0d65a1880695ac511d3a3af5  AA030 GitLab.txt
$ md5sum .AA030\ GitLab.txt.~7daada06 
054bf21d0d65a1880695ac511d3a3af5  .AA030 GitLab.txt.~7daada06

I 've edited some info out. Both files have 20 bytes file size and give identical md5sums. However the client says they are not the same.

I also went in on the server, a nextcloudpi instance, checked the file in $NCDATA/$user/files/$path_to_file and the file had the same size and md5sum.

This is the code that generates the warning. However since I can verify that the files both have the same size and are identical there must be something wrong in how the variables doing the comparison are created.

On top of it closing and re-opening the client doesn't solve this problem. The client seems to enter into a loop. It looks for changes, finds that it has to sync some files, starts syncing them, gets the same error again on the same files and completes the synchronization. Then it starts to sync again!

I tried closing the client after a sync loop/cycle and manually deleting the temporary files. It didn't work. The exact number of temporary files re-appeared after I opened the client! It looks as if there's a state stored somewhere that re-created but I can't be sure.

I also tried removing removing the ._sync_6c3bfe3b6166.db file in the root directory. However this resulted in the client behaving as if it had just established a new sync connection and tried to sync things from scratch. During that sync the error resurfaced again.

Sample commands used for this:

# See number of files that produce error
$ find ./ -name .*~* | wc -l
109
# Close nextcloud-client and delete temporary files
$ find ./ -name .*~* -exec rm {} \;
# verify files were deleted
$ find ./ -name .*~* | wc -l
0
# see files re-appearing after a full nextcloud-client cyle
$ find ./ -name .*~* | wc -l
109

Information on my system are (basically a new Fedora MATE 30 install):

$ cat /etc/os-release 
NAME=Fedora
VERSION="30 (MATE-Compiz)"
ID=fedora
VERSION_ID=30
VERSION_CODENAME=""
PLATFORM_ID="platform:f30"
PRETTY_NAME="Fedora 30 (MATE-Compiz)"
ANSI_COLOR="0;34"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:30"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f30/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=30
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=30
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="MATE-Compiz"
VARIANT_ID=matecompiz
$ uname -a
Linux enclave 5.1.8-300.fc30.x86_64 #1 SMP Sun Jun 9 17:09:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ dnf info nextcloud-client
...
Installed Packages
Name         : nextcloud-client
Version      : 2.5.2
Release      : 2.fc30
Architecture : x86_64
Size         : 8.9 M
Source       : nextcloud-client-2.5.2-2.fc30.src.rpm
Repository   : @System
From repo    : updates
Summary      : The Nextcloud Client
URL          : https://nextcloud.com/install/#install-clients
License      : LGPLv2+ and GPLv2
Description  : Nextcloud-client enables you to connect to your private Nextcloud Server.
             : With it you can create folders in your home directory, and keep the contents
             : of those folders synced with your Nextcloud server. Simply copy a file into
             : the directory and the Nextcloud Client does the rest.

update: This issue also appears with the latest appimage daily build.

[iwitz]

Hi, I compiled the desktop client from source about a week ago to make sure it included the latest changes and the fix for #1000 but I still couldn't synchronize files on Linux. After disabling the end-to-end encryption module through the Web interface, I was able to synchronize files, but without E2E encryption.

[riggs498]

I am still on 2.3.3 I will not change until till the errors are fixed. I
have to many clients for these errors. 2.3.3 has not failed me yet.

Thanks,

Ryan

On Sun, Jun 16, 2019 at 1:02 PM iwitz [e-mail] wrote:

Hi, I compiled the desktop client from source about a week ago to make
sure it included the latest changes and the fix for #1000
https://github.com/nextcloud/desktop/issues/1000 but I still couldn't
synchronize files on Linux. After disabling the end-to-end encryption
module through the Web interface, I was able to synchronize files, but
without E2E encryption.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nextcloud/desktop/issues/876?email_source=notifications&email_token=ADTNHB74FM2SGHZZZP4D2PLP2ZW3XA5CNFSM4GF443G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZRCDI#issuecomment-502468877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADTNHB7E7BI2AOPV4EAPWNLP2ZW3XANCNFSM4GF443GQ
.

[Iolaum]

I gave in and switched to 2.3.3 as well. Compared to 2.5.x (I 've used all versions to date) it's a breath of fresh air. Syncs faster, doesn't randomly go at 100% cpu utilization from time to time and does not crash every now and then.

I know the NextCloud team are aware of the issues and are tying to address them, I wish them the best of success.

[bestouff]

I have a problem where some people don't see all directories with the desktop app, whereas in the website they can access everything.
Do you think it's related or should I open (yet another) issue ?

[warnerbryce]

@Ralayax on the website note. That would be possible, but in my mind that would need three things:

* the bug is not present in 2.3.3 (do we know that, did anyone try that yet?)

I would consider it, for sure - but I'm really not convinced this is a problem that happens often enough that users should use the old version of the client. Keep in mind that, while it has this issue, the new client also does a lot of things better than 2.3.x did...

Yes the 2.3.3 is more stable form any 2.5.X Windows/OS X/Linux
Everytime a client have sync problems with 2.5.X i install 2.3.3 and then no more bugs.
I have some clients that don't have problems with 2.5.X but it's only 20% of my clients.

[andreaslink-de]

Does anyone know, if this issue is fixed? We are currently at version v2.6.1 and a lot was fixed, but this was now mentioned. Just wanted to follow-up, based on your experience, if it's worth updating to newest version?

[nursoda]

I have LOTS of errors with files bigger that a few kByte ATM. Havn't found out yet whether it's a client or server issue. I suspect client issues, so my tip ist to stick to it for now if you have a stable version.

Plus, 2.5.3-2.6.1 have poll frequency of 5 secs (instead of 30 secs in earlier versions). With many users, that produces quite heavy load. One may mitigate that by adding a config line in local nextcloud.cfg - not a big deal if you just use NC for yourself, but with several hundred users, it's a mess.

[Peac]

Does anyone know, if this issue is fixed? We are currently at version v2.6.1 and a lot was fixed, but this was now mentioned. Just wanted to follow-up, based on your experience, if it's worth updating to newest version?

For me, this bug is fixed. Files in subfolders are synced correctly, also for nested cases like subfolders with several subfolders and files in each of them.

I have LOTS of errors with files bigger that a few kByte ATM. Havn't found out yet whether it's a client or server issue. I suspect client issues, so my tip ist to stick to it for now if you have a stable version.

I have more than 10k files with sizes ranging from bytes to several hundred megabytes without issues.

[misch7]

Plus, 2.5.3-2.6.1 have poll frequency of 5 secs (instead of 30 secs in earlier versions). With many users, that produces quite heavy load. One may mitigate that by adding a config line in local nextcloud.cfg - not a big deal if you just use NC for yourself, but with several hundred users, it's a mess.

The fix to revert this to 30 secs should have made it into v2.6.1 but didn't. I cherry-picked it now so it will be in the 2.6.2 release.

[carlfriedrich]

I am happy to confirm that this issue is no longer present in 2.7.0-rc1, obviously fixed with #2139. Thanks a lot to the developers. Looking forward to the final 2.7 release.

[er-vin]

Thanks for the confirmation, I'm closing it then.

[abejaranoh]

Will this package (2.7.0) be available on Debian Buster? Currently 2.5.1 is in the repos.

[er-vin]

That's a question for @ivaradi I guess. Also note that 2.7 became 3.0. :-)

[abejaranoh]

@er-vin @ivaradi thanks. I dont know how many people are facing this problem but then updating debian from 10 buster (with nextcloud 2.5) to 11 bullseye (with nextcloud 3) just beause of the nextcluod client is a lot of work.

[ivaradi]

@abejaranoh as far as I can tell, 2.7 or 3.x will not be available for debian buster because it depends on a Qt version that is not available in buster.

[DanScharon]

Usually a case for backports then. But backporting Qt sounds like a huge load of work.

[DanScharon]

@er-vin @ivaradi thanks. I dont know how many people are facing this problem but then updating debian from 10 buster (with nextcloud 2.5) to 11 bullseye (with nextcloud 3) just beause of the nextcluod client is a lot of work.

you may want to look for flatpak then: https://flathub.org/apps/details/com.nextcloud.desktopclient.nextcloud

[abejaranoh]

i m using 2.7 as appImage... its solved for me...thanks