The problem is known and lot of users are affected. for details see Desktop Pre Release 3.4.0-rc1 - help test! - #3 by wwe or related Github issues below.
@rakekniven please pin a warning to NOT upgrade the client to 3.4.0 (problem might be related to VFS)
I dropped developers a notification as well.
Hi all,
We have disabled the updater & removed 3.4.0 from the download page - for now, we are hunting down this bug and will release a 3.4.1 as soon as possible that should fix it. Unfortunately it is in a very old code path that seemingly got triggered in some situations with the new bulk upload.
I do believe this only hits on systems with Nextcloud 23/Hub II, but I will try to get confirmation for that and if you have evidence to the contrary, let me know.
EDIT: no, it also hits on older versions. 3.4.1 will have to fix it.
I’m sorry for the bug - clearly not enough people tested the 3.4 RC’s - if you have any suggestions on how we could get more volunteers to test our release candidates, let me know!
You are welcome @jospoortvliet It’s definitely annoying to hit such invasive issue and the need to perform unplanned restore (is there any “planned” restore?) of your server over the weekend… but everybody knows each software has bugs.
The bad thing is the fact that logic problem behind the issue - the clients always upload it’s local state to the server - is known since months 
I think, getting voluntary beta testers for a sync client is really hard. The bugs that those people will encounter may seriously screw up their data. 
is the proposed fix going to fix the data issue this has caused? Or is my data hosed and I have to restore from a backup prior to installing desktop 3.4? Honestly I feel you should increase RC testing period.
I think there will be no short term a fix to recover from this issue. I think at the moment restore is the best option you have. Fortunately this bug doesn’t cause loss of files itself… only metadata is (created/modified timestamp) is lost and there is useless network and storage consumption… but depending on your hosting model this could become a problem as well…
I created a feature request on Github to get some command line support for managing versions and trashbin so you could recover your files - please support it!
Just a few ideas:
I agree with @marcelklehr that testing a sync client might be tricky, because bugs can have a huge implication.
Maybe related is that the main dialog won’t open as well.
I’m on linux ubuntu and downloaded the app image 3.4.0. That seems to be working ok. main dialog opens and the sync has completed and now is idle so maybe it’s related to the build and dependenices at least for unbuntu focal since the app image build seems ok.
FYI I have 3.3.5 loaded on another machine. no issues with it.
@jospoortvliet We have this problem with NC server 22.2.3, so please don’t concentrate on NC23 as trigger for this bug.
Yah, restore is what I ended up doing. Thankfully the nature of this bug is it only effected files that were synced under 3.4.0. So first I downgraded back to 3.3.6 and restored only the groups of files that nextcloud kept retrying to sync.
It needs more incentives. Sync performance on small files is an issue for a very long time and if you promote such a solution, people are perhaps more willing to test this. A long time ago, I tested a few this on a raspberry system myself to see the influence of redis and the database caches (Upload performance OC 8.2.1 (50 mysql queries per file) · Issue #20967 · owncloud/core · GitHub). But it takes you easily a day and with all the follow up more time.
But this time, unless you are excited about the backup app (🛠Nextcloud 23 RC 1 is here - testing time!), I wouldn’t get the idea of testing the sync process.
That was the major feature for this release: fast syncing of small files:
I hope this will then make testing consume a lot less time…
For you that is obvious. There is nothing in the RC1 news. Yes you can go back, you can check on github, … You announce it one day, then there is a release, you don’t mention it again, even the discussion from last time with the announcement, you don’t repost to say that now there is something out, that people might want to test. Also tons of posts with sync performance with git repositories etc.
The thing is, you want people to test it, so don’t make it harder than it has to be.
The issue isn’t solved yet, but perhaps it can be figured out which platforms and environments need better testing.
yeah, I know I failed to mention that more clearly in the requests for testing. But my reply was more at your comment that testing takes a lot of time because the file sync is so slow - that should, going forward, be a lot faster, which hopefully makes testing less of a pain.
Ok, I didn’t mean that either 
It’s just in general, setting up an extra environment, installing another client etc. takes a lot of time. If the upload takes 2h, I don’t have to sit there and watch. And if I do this effort, I either want to learn something, or get some benefit ot of it, like a new feature I was waiting for a long time.
I don’t think “incentives” would help. In my eyes testing is the hardest part of the development process as you don’t have clear defined goals like “it compiles let’s sell it” ( only joke ). working through well designed runbook and carefully looking for issues which might be not obvious… especially client testing is really hard - running this in production is bad idea, finding good test coverage with production like usage (don’t forget all the moving parts like client reboots, hibernation, network outage, software updates, interaction with other software packages like anti-virus, different OS…) is a nightmare - I don’t think you can count on this forum to find highly trained people + willing to spend big amount of their spare time + to test beta software…
If you want good results - testing must be done by the most experienced people you have - this is the reason majority of testing should happen close to the devs - they are expected to be familiar with the product, know where to look in case of issues and can involve their colleagues fast… This forum can help when it comes to real-life testing on different platforms and cover all the variations of real-world installations… but this must be the very last testing stage with solid, well tested versions you already consider production ready but need last confirmation.
I’m the last one who blaims you for this specific bug - I know the competing market, demanding customers - but I think there is huge room for improvement in communications between Nextcloud GmbH and the community as discussed in depth here
I don’t think for regular updates. But regarding new feaures, they did it differently for the virtual file system, first it was an alpha-feature, disabled by default.
The problem with the community, you don’t know what systems are tested and which environments. As you said, you need to cover a huge amount of different scenarios.
The first releases after the fork, I had the impression that the whole story of reliable updates was improving. People trust Nextcloud with data, sure you should have backup and everything. But how often will you do a restore from backup before you ditch a product?