@jospoortvliet Youāre absolutely right we need more users to start testing the RC versions. Id be happy to volunteer my time to test and report issues.
Yes, RC version can cause issues with users data but for testing why not have a test profile, test computer or vm so it only has the RC version and incase of an issues you donāt have to worry about your data. Thats the whole point about the project we all have to put in some work. The devs can only test so much. I get we canāt get everyone onboard with testing but if we want a better product we should. Yes, I agree with everyone that V3.4.0 caused alot of issues and i was one of the admins that had to do a restore as well but at the end of the day we cant only blame Nextcloud. Thats the reason why this wonderful application is free and open source so the community āusā can make the product better.
Thanks for the input all. This time I really shouldāve done better by talking about the new bulk upload feature when asking about testing, as this feature was already talked about, that was really a mistake. It might have made a difference in testing.
In the future I will try to do that, too. Sadly generally we donāt yet want to spill the big features, while with small features weād be happy to talk about the motivation is probably low, but thatās a problem for the future.
In the mean time, I can tell you the desktop client team is debugging hard, working with the server team - there are both server and client issues, it seems, though I guess the server issues are in the new code for bulk upload. As soon as we have a fix weāll publish it of course.
Would it make sense to have the announcements around RC1, instead of Release? Maybe more people would be willing to test, if itās clear, whatās coming. Would also give you time to fix any critical bugs towards release and would be a good time to remind app developers to make sure their apps are compatible with the latest version / for release.
@jospoortvliet Thanks for the update and the explanation!
To answer your question about how to make more people test the RC, a few ideas:
Provide a test server, including dummy files, folders, ā¦ so that any tester can log in, install the client and start testing, without having the risk to lose any data (similar to what @AndyXheli proposes)
I like the ideas above to communicate about RCs and new feature, to make it more appealing
Propose a bonus to people who report feedback (notably the ones finding bugs). Bonus could be ā2 hours of consulting/advice/audit provided by a Nextcloud engineerā (so that the tester receives advice on their own Nextcloud setup for example), a higher priority given to features suggested by the tester, ā¦
At each release, remind to the community that testing RCs is super important and that Nextcloud needs it
Regarding 3.4.1, do you plan to release a RC that we could test? [edit, oups, yes, you wrote it above ]
In general, I think this question is key and would deserve a dedicated discussion, with a lot of publicity so that the community gets really involved.
A 3.4.1RC is here for testing. We improved the reliability of the sync process to better deal with the bug and it seems to fix it. Of course I still should point out that this is a test version, you should backup your data etc!
That said, the more realistic the test case, the more useful the testing is of courseā¦ As usual, any feedback is welcome below here!
sadly no, also with earlier releases. It seems the bulk-upload additions have triggered something bad, even though the bulk upload is only active in Nc 23.
@jospoortvliet I had the issue before on Win 10 + NC 22.2.3 (Docker) and Iām willing to test but it would be great if you show some recovery steps without restoring the whole instance - just in case it is not fixed and happens again - last time the restore took me 3 hoursā¦
Maybe you can share some manual steps to find out affected files and restore valid versions using some commandsā¦ as I asked in
I sadly donāt really know how to fix these things, Iāve asked one of the desktop client developers who incidentally also has sysadmin experience to pitch in.
the nature of the sync makes it hard to predict what happens and whenā¦ desktop clients are little unpredictable on what and when happens (long scanning phase then fast uploading) and Iām little discouraged to run the test again with possible ābenefitā of another 3 hours restoring my instanceā¦
We know the problem occurs somehowā¦ you suppose to have valid fix related to batch upload featureā¦ but from my understanding it doesnāt really matter how the client uploads the files, one by one or in batches there is absolutely no reason to touch the ctime/mtime of the filesā¦ and if you are not 110% confident the fix works itās better to spend another day to think about recovery strategyā¦ velocity is not always the key - especially in such situation when bug has huge impact on the whole instance keep calm, step back and deliver first time right and avoid braking same system twiceā¦
In my eyes itās worth going the extra mile and start with intentionally brake an installation with 3.4.0 over additional recovery step (to verify it works) rather just going fast forward to the āfixedā state - especially if you think about the customers who still receive buggy 3.4.0 update through different channels and may hit the problemā¦ or others who might not have recognized it nowā¦ we have a chance to give them a helping hand to recover from an issue rather telling them - āitās you business to have good backup strategy and this is a good chance to test the recoveryā you can count on me if you choose this wayā¦
]
Mac OS X: 
Linux: 
- so it should be 
- last time the restore took me 3 hoursā¦
you can count on me if you choose this wayā¦