Ofcourse it is a risk but so is using Nextcloud desktop.
I use a nextcloud server (16.x). For me the nextcloud client does not work but the owncloud client does (windows 10, client certificate). Someone I know also uses the owncloud client on his mac successfully.
thx for reply
Iām wondering why the Nextcloud Virtual Drive client is not supporting TLS 1.2.
Iām sure we can all agree that supporting TLS 1.3 is a Good Thing. However, why would it not also support, at least at this time, TLS 1.2? The devs are severely limiting testing and adoption by requiring anyone who wants to test this to have their Nextcloud hosting support TLS 1.3 and 1.3 only.
I realize that my understanding of this may be naive, and perhaps there is a lot of additional development effort required to support both 1.2 and 1.3. Enlighten me!
If you get nextcloud up and running on a VM it is not that hard to upgrade to tls 1.3. if your provider doesnāt support 1.3 ask them why.
But for a wider adoption of testing. Perhaps 1.2 should have been included. But getting 1.3 on the server is not hard if you have everything installed.
I use it in a production mode and i warned the users.
And of course it works, but sometimes the files inside some folders get vanished. No .owncloud files nothing. So you have to right click -> unsync. Wait. Right click -> full sync and wait.
Nextcloud didnāt copy paste the owncloud virtual drive because it didnāt comply with the way they think Virtual Drive.
Apparently, there are several issues with the current NC 2.6.1 desktop App on Mac OS X / macOS.
Please consider to use the bucket list to get some awareness. What do you think?
Happy hacking.
Hey, do you have any news about this? the least to say is that communication about this is not goodā¦ so many different interpretations and no one to clarify anythingā¦ 
Hey Camila, i followed your recommandation to post on GitHub. Now two month later, not an answer or anything from someone from nextcloud has been posted, just me and other people wondering what is going onā¦
@camiliasan on github is very discrete.
I think (but itās my only opinion) that the development of this feature get stuck at some points. Itās not finish yet, not ready for productionā¦
I stopped to dream about this feature, iāll just be happy if this feature comes out of Beta.
Itās strange that they still didnāt communicate about the sentence āWe will leave full sync for Virtual Sync onlyā. For the moment i hope they changed their mind.
You can test the ownCloud client but the Nextcloud approach is different and even if Virtual Drive is in production mode at ownCloud, itās still comes with a lot of bugs.
Yes, I really donāt get that silence on this matterā¦ Everywhere it is quiet and that is frustrating.
Why a virtual drive instead of smart synch of files?
If someone could just explain what the advantage is of having a client-dependent virtual drive over a ārealā folder (that does not disappear when the client is off) with smart synched files?
I really donāt get what it is?
Especially as the virtual drive solution EXISTS ALREADY with mountain duck!!!
It is exactly what they are describing at the start of this post. Why are they reinventing the wheel? (For all those wanting a virtual drive, just use mountain duck instead of waiting hereā¦)
I guess that with a virtual drive, the storage back-end is transparent to the applications that want to read or write to it. This means it should be possible to open large files without downloading all of it first. For the typical home user it would mean you can stream videos, pictures or music without the possible long delays in syncing.
Obviously it would be important to be able to select what files or folders to keep offline.
There is a misunderstood of a lot of people about the Virtual Drive.
When you start for the first time the Nextcloud Client with Virtual drive. It creates the Whole folder/files architecture of your nextcloud account. But it download nothing. All the files are just less than 1 Kb one.
Then you can left clic on folders you want and clic on Ā« available offline Ā» and then the folder sync as it does normally with the legacy client.
But the more important when the first start is made, if you lose internet you are still connected to the Ā« fake Ā» network drive that Nextcloud created.
You can visit all the folders, and you can only interact with the files youāve already downloaded.
The left downside then is that one cannot sync directories from across the system, I guess? This breaks my personal use case where I sync different directories from different locations across the clients file system to server. And I like the possibility to remove/pause/re-enable sync for each of them individually.
Also I assume a virtual drive to be available aside of other mounted drives. This most likely is more a feeling and a question of habituation, but I donāt like files I work on being available from any other location than my own chosen folder structure. I want my files located at, and only at /my/chosen/path (and others at /my/second/path) and not some F:/ virtual drive mount letter. This just feels like an unnecessary overhead and messes with my clean explorer view.
So basically I like the choice to download required files only and keep others available on demand. This is an additional feature as long as I can mark everything for offline at once, hence no downside. But to not destroy any users current work structure/flow/habits it needs to be possible to:
.Yes thatās true.
That why i pray for having the choice !
Because user cases are so differents.
They said that they will rethink the question. But at the moment we didnāt get news about that.
Thanks Nemskiller for your explanations and I totally understand the idea āavailable offlineā etc.
My issue is the one that Michaing is describing better than I am (sorry for that):
I donāt see any advantage of having a drive mounted and dismounted with launching the nextcloud client to see the files/folders.
(also, again; where is the difference with mountainduck regarding this way of working?)
I do understand that my offline files are still on my computer when Internet is down or the client would not work, But the virtual drive does not appear in the finder/explorer and my files are somewhere in some obscure path in the system. (again, like mountainduck is working right now)
Instead of a chosen folder like now, which does not move when the client or internet is down.
Exactly the issue Iām having and which Iām wondering why they choose that way?
+10000
The desktop client still lacks developer manpower (see how many issues arenāt even tagged let alone replied to or even fixed) and the newer releases of the desktop client have some very troublesome bugs that arenāt fixed (some people still use 2.5 or even 2.3 either because of these bugs or because they donāt know a new version exists because the updater didnāt work till 2.6). It would be better to stop creating new features and start to fix serious issues in the existing implementation. Same goes for E2EE which is still not out of Alpha quality.
Also, it would be good to refrain from implementing features in parallel that others already did (Mountain Duck/Cyberduck/Cryptomator) to save energy for really important stuff (like reliable syncing). But I think this is a bit like KDE is done if you know what I mean.
I think this would break the workflow of a lot of people that they use now for many many years already. Removing the folder based sync would be a very bad idea for all those people and a lot of sysadmins and users alike will be very unhappy with this (let alone switching all of them to the new way of syncing).
Please listen to your users, the Gitlab backlash should be a lesson to everyone about how to not do things.
I am most concerned about the reliability of this solution. My biggest problem with how the proposed virtual drive works is that the virtual files disappear if the client stops running. So if it crashes due to a bug, or is prematurely shut down, or is killed, or misclassified by antivirus (as false positive), etcetera, and you have any files unsaved or open, you will get data loss. This is a huge risk. A risk that is completely non-existent if only they used a normal folder with normal files, like many other software do (for a good reason).
@Ka_Pa ā Good point. Excellent argument. I consent.
@ ALL ā Please think first, act second only and always have the protection of your data in mind.
Agree - some certainty would be helpful. The Thunderbird 68 update hit my desktop a few days ago and brought into stark clarity how much of a hassle it can be to have developers switch paradigms against their user base.
In my use case, the ability to control sync at a folder level is critical. It might be possible to simulate that with lots of RSYNC scripting against the āvirtual drivesā but thatās kind of horrible to contemplate and means an awful lot of computer overhead on hashes and layers of things that can go wrong. If NextCloud really wants to abandon the existing user base this way, is there any indication of OwnCloudās commitment to their existing users? The uncertainty of such a massive āpivotā looming is quite enervating.