Virtual Drive Project - Use Folder with "smartsynch" instead of a Virtual Drive that runs only when client runs

[MoloSeb]

After feedback by camilasan on the nextcloud forum, i'd like to post this suggestion i made there also here:

After reading lots of questions and answers, i’m still wondering why it has to be a virtual drive instead of a folder?

Correct me if i’m wrong but the idea is to be able to choose what file are to be synched and which are to be only downloaded on demand, to spare some local space and have the files online.

Why is the development not making a dropbox-like solution (they call it smart-synch)? (which, if i interpret lots of remarks of this post correctly, is what people would like?)

• you do have a “real” folder (not a virtual drive letter) where you see all your files.
• All your files and folders are listed in that folder.
• By right clicking on it and changing that “status” you can choose which file/folder has a local copy and which one is stored online-only and downloaded on demand .
• The files/folder where you decide to be online only are visible but they are placeholders which even show previews of the files, but it is not the “real” file
• when you are offline or should the client would work, you would still see all your files, but only the ones you have set as locally available are real files, the other are the placeholders.
• You don’t need a virtual drive but you have a folder like it always has been and you keep the same hierarchy/ order wether you are online or offline so you can find your files easily.
• But you have the advantage of saving some space by keeping just “real” local copies of what is needed.

I hope I make some sense, but IMHO the way to have a virtual folder is just complicating everything ? Sorry if I’m missunderstanding something…

To sum up, IMHO i don’t know why the idea of a virtual drive seems to be predominant instead of working with the same folder just with “smartsynch” technology (or whatever it should be called).

As I tried to explain, it seems to me that having a virtual drive that only shows when the client is running as the solution for a smartsynch alternative would be reinventing the wheel by complicating it… It is already working like that in:

• dropbox,
• onedrive,
• seafile,
• owncloud (there it is called virtual file) and surely others...

I added a screenshot of the smartsynch solution, just to be clear how it looks for those who might not have seen it.

[pylorak]

Agreed. Also, the fact that the client needs to be running to make the real file contents available as a virtual drive is a huge data risk. While the NextCloud client is pretty stable in general, I did have it crash once, and there is no guarantee there won't be a bug in the future that will cause crashes. If any files are open when the NextCloud client exits or crashes, files will be corrupted or work will be lost. External factors can also cause the client to exit too early while there still is unsaved work, like a bug in Dokany or other external dependencies, antivirus software false positives, or automatic termination at system shutdown, to name just a few from the top of my head.

Generally, it is strange that all those other services evaluated their options and have (understandably, given the risks in NextCloud's approach) all come to the same conclusion, but NextCloud alone still thinks it is best to go his own way.

To sum it up, I also vote for the files (all or user-selected) to be available even when the client is not running. The only advantage of the virtual drive compared to the old client now is that directory contents can be shown even for file and folder contents that have not yet been synchronized, which is cool and ok, but that can be achieved with placeholders too like other synching services do, without the inherent data corruption risks that NextCloud has opted for.

Lastly, please note there are many people having similar worries, we are not alone. See the countless disapprovals of the virtual drive feature in the forum thread here.

[MoloSeb]

THanks for that support, i'm just wondering why there is no official position or answer on this? (the forum post you are linking to is the one i wrote before here and where i was told to write here :-) )

[pylorak]

i'm just wondering why there is no official position or answer on this?

This ticket is only open since 3 days, and this is a major design decision / issue. Give them time to discuss internally, evaluate, and collect more feedback. This can take time. Until then, we can only hope that other users will join here too to show they agree with our proposal.

[Schmuuu]

I'm really wondering why so many people think that other solutions work without a client software. OneDrive, DropBox and so on, which use this "smart sync" need a client/ daemon too. So there won't be much of a difference compared to the NC client.

It is just a very small step to create a service for the client, so that it is automatically restarted in case of a crash.

If any files are open when the NextCloud client exits or crashes, files will be corrupted or work will be lost.

This is what temporary work files are for. Every smart sync is no smart sync when a crashing client or an interrupted network connection cause file corruption. And the new NC client feature will of course be that kind of stable/ reliable smart sync (maybe just not named like that).

i'm just wondering why there is no official position or answer on this?

I can only guess, while I'm neither a developer nor an official, but I can imagine that officials feel the way I feel meanwhile: exhausted from all the misunderstanding. Sure, there are suggestions which are totall valid, for example the one to be able to specific the hard disk and the folder where the virtual drive really stores the files on the client. This is something one can think about.

An advise: suggestions should be focused and not littered with additional complaints in order to be heared easier. The rather small development team is focusing on development and doesn't have much time to read everything here and answer to everything. That is why most questions should be directed to the community in the Forum and only issues/ Enhancement Requests / specific questions, which can only be answered by insiders/ developers should be placed here.

[pylorak]

I'm really wondering why so many people think that other solutions work without a client software. OneDrive, DropBox and so on, which use this "smart sync" need a client/ daemon too. So there won't be much of a difference compared to the NC client.

But that is a daemon (or service in Windows), as you say yourself, which usually has much less complexity and a lot better controlled lifetime (start/stop/termination) than desktop apps. That is a huge difference from a reliability perspective.

It is just a very small step to create a service for the client, so that it is automatically restarted in case of a crash.

But NextCloud has not taken this "very small step", as you put it, and there has been no indication by the devs that there is work towards it. This "small step" is rather important, and until it is taken, our critique stays valid.

If any files are open when the NextCloud client exits or crashes, files will be corrupted or work will be lost.

This is what temporary work files are for.

Temporary files can only prevent corruption, not loss if saving is impossible. Also, it is outside the control of both NextCloud and its users whether a 3rd party app uses temporary files or not, and since many software do not, NextCloud should not and cannot rely on it.

Every smart sync is no smart sync when a crashing client or an interrupted network connection cause file corruption. And the new NC client feature will of course be that kind of stable/ reliable smart sync (maybe just not named like that).

Not true. The naming obviously doesn't matter. But when synching is interrupted, the server-copy might be invalid or non-existent of course, nevertheless the local copy will still be intact even with a crashed synching client or a broken connection, and it will be re-synchronized correctly next time the connection is restored (this is how the current client works). But this is impossible if the local copy was already corrupt (or not corrupt but unsaved) to start with, which can obviously happen much easier with the proposed virtual driver feature.

An advise: suggestions should be focused and not littered with additional complaints in order to be heared easier. The rather small development team is focusing on development and doesn't have much time to read everything here and answer to everything. That is why most questions should be directed to the community in the Forum and only issues/ Enhancement Requests / specific questions, which can only be answered by insiders/ developers should be placed here.

MoloSeb was explicitly asked by the NC team to open an issue about his proposal here. Others obviously need to show their support here too otherwise the NC team will think he is alone and will not lift their fingers. I brought in data loss/consistency issues to support and underline why I think MoloSeb is correct about his proposal, it wasn't an "additional complain", but a new argument for the original proposal.

[Schmuuu]

This is what I mean, with exhausting. And I don't mean it in a mean/ nasty way. You somehow seem to think the developers of Nextcloud are not competent enough (stupid) to build a software which prevents data loss. I don't know why that is actually. Nextcloud has big customers and the biggest customer with Millions of users. Don't you think that these customers very much care about the topic data loss and that therefor Nextcloud will take all precautionary measures to not loose any customer's data.

And yes, sometimes a software crashes, this happens to every software from every vendor. DropBox and OneDrive had issues, too. Nobody('s software) is perfect. But these issues will be fixed as well. Right now there is a lot development going on and of course internal testing as well.

And yes, proposals should be posted here. What I mean with littered however is, for example:

The files/folder where you decide to be online only are visible but they are placeholders which even show previews of the files, but it is not the “real” file

This is already handled be the client. So it is not very focused on what actual behavior should be changed or which feature should be added. Don't get me wrong, I want the client to be perfect as well and I see a few valid enhancement requests here, but please leave out the stuff which the client is actually all about ;) Like all these three points:

• By right clicking on it and changing that “status” you can choose which file/folder has a local copy and which one is stored online-only and downloaded on demand .
• The files/folder where you decide to be online only are visible but they are placeholders which even show previews of the files, but it is not the “real” file
• when you are offline or should the client would work, you would still see all your files, but only the ones you have set as locally available are real files, the other are the placeholders.

[MoloSeb]

Hey Schmuuu, thanks for your feedback. I just thinking we are talking in circles (i hope the expression makes sense)

My concerns are just regarding usability, I'm not as worried about file corruption, since, as you say, i'm sure nextcloud devs are aware of those risks and doing their best to prevent them.

I'm really wondering why so many people think that other solutions work without a client software. OneDrive, DropBox and so on, which use this "smart sync" need a client/ daemon too. So there won't be much of a difference compared to the NC client.

I never said there should not be a client running. I'm just concerned about why having to have a VIRTUAL DRIVE? Like shown on the initial screenshot on the next cloud page? That drive would "dissapear" when the client is turned off for what reason ever and it becomes a mess to find your files back on your system? Why not have a FOLDER? (like now) and add those virtual file/ smart synch (called it like you want) functionalities to it? That is what i'm asking about. Just a Usability question:

Also, sorry for littering my issue, I just wanted to be as clear as possible and to explain step by step how the client and it's file management should work. Seems to not have worked and I'm sorry to have bothered you with that :-(

To sum up my point as simple as possible:

• Why a virtual drive that would disappear when client turned off? What is the advantage?
• Why not a folder with "smartsynch" functionality? That folder would not dissapear should you turn off the client for whatever reason and you could still find your files easily.

As far as i have read all posts, I couldn't find an answer to that usability question.

[MoloSeb]

So, no answer to the initial question? Can somebody please explain the choice/advantage of a virtual drive? Please?

[MoloSeb]

Anyone with an answer??? ANYTHING? PLEASE?? WHY A VIRTUAL DRIVE that vanishes when the client is turned off? WHY NOT a classical folder with virtual files? I'd just like to know what motivated this choice? What is the practical advantage? It's frustrating to wait so long for a any answer. So many people asking for this and not one "official" answer... Not here, not in the forum...

[MichaIng]

For reference: https://help.nextcloud.com/t/nextcloud-introduces-virtual-drive-in-desktop-client-to-simplify-desktop-integration/46256/195?u=michaing When network connection is lost, files are still available. There are other left possible downsides I mentioned, but those are not too critical.

[r-jasper]

The advantage of a Virtual drive is that No space is taken whatsoever. If one wants the files locally, a little app to sync with a local directory will do the trick. This is also how pCloud implements this. It will create a virtual drive (P: on WIn, pCloud Drive on Mac), and pCloudSync is available to sync local files/directories. I do have very good experience with it (on MacOS & WIn)

[er-vin]

I can already say that it won't be a drive letter but a folder holding the virtual file system even on Windows. We did that change in the virtual filesystem work branch already.

So hopefully nobody mind if I close this one.

[r-jasper]

OK, and when do you think it becomes available?

Op 22 okt. 2020, om 13:01 heeft Kevin Ottens notifications@github.com het volgende geschreven:

I can already say that it won't be a drive letter but a folder holding the virtual file system even on Windows. We did that change in the virtual filesystem work branch already.

So hopefully nobody mind if I close this one.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nextcloud/desktop/issues/1476#issuecomment-714414193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKMRFITX74WAH42CJ5LBP3SMAGIPANCNFSM4I5XYKIQ.

[er-vin]

Still months away I'd say.

[r-jasper]

Pitty, for my use a show stopper… I’ll have to wait! Thanks,

Rob.

Op 22 okt. 2020, om 14:20 heeft Kevin Ottens notifications@github.com het volgende geschreven:

Still months away I'd say.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nextcloud/desktop/issues/1476#issuecomment-714455053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKMRFP2Y2KJ5EYFIPAC2DDSMAPR5ANCNFSM4I5XYKIQ.