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
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!
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.
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.
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?