To Do in 2018 - Priorities for your roadmap


#1

I’m a new oDrive user - been a customer for about 2 weeks now.

I previously used Insync, which was good in many ways, but a poor customer focus/user experience and problems with duplicate files being created for no sensible reason drove me to look for an alternative. So here I am.

The feature list of oDrive is pretty good, and ticks most boxes on paper. Initial impression was positive.

However, so far, I am experiencing a product that is riddled with bugs, and a product that is far from nailing the UX.

Recursive Automatic Sync doesn’t work.
It has a bit of a go, gets bored after a while and decides to have a siesta, declaring it has finished all syncing whilst I stare at a ton of .cloud and .cloudf files… Manually telling it to sync is generally ignored. It just fails silently…

I checked these forums and suggestions are to use a small bash script to manually force recursive search for .cloud files and force download them. This is horrible. Why on earth are you making me do this? Are you insane? Why is this not just fixed in the product? I would get it if the issue occurred in the last month as a temporary fix like that is super helpful, but this has been going on for a year and a half! Even if you have to cobble together this script into the app, it would still be a better experience for me. This is a core function of your software - this is the whole reason I purchased it - to sync automatically a local and remote copy of my files. You are failing at the core feature of your product. And you haven’t fixed it in over 18 months? What are you doing?

Finder Extension is riddled with bugs
This barely works. More often than not the status icons don’t appear next to some folders and files, but they do others (regardless of sync status). Sometimes they disappear completely. Often they flicker so hard that I’m just glad I’m not epileptic.

Worse, more often than is acceptable, the context menu doesn’t have any options (“No Options Available”), which is disastrous when you base you entire interactive UI around this - I am unable to control whether something is syncing or not, and I cannot use any of your additional features (like share). This is a UX design failure, as well as a shitty bug.

Even when the above aren’t manifesting, the icons are still fairly useless as they don’t show the recursive state… in other words they may show a (tick), yet the contents in that or its subfolders may not be synced. This is quite useless when you think about it, as one would naturally use this as a visual aid to understand whether an area is fully synced or not. You need more than a tick and ‘doing stuff’ - show me the difference between a downloaded folder, partially downloaded, synced, etc, etc.

Confusing UI/UX
The experience so far has been a bit on the confusing side. I am of course more used to the idiosyncracies now, but even so, I still cannot easily tell which folders are set to sync, vs sync+download, vs placeholder, or their current state (see above). Spreading this out into the finder interface has some benefits in terms of specificity and direct manipulation, but makes it difficult to understand the big picture and see misconfigurations or their current state. This means it is quite hard to understand if things are setup correctly and the process is working - so I am now paranoid about it not working and me only finding out that my critical file is not available offline when I need it most.

The ‘sync to odrive’ is also a bit confusing - I had initially synced the contents of my drive, and wanted to ‘map’ to my local built in folders (on the mac), such as Downloads, Documents, Pictures, etc. What I didn’t realise is that it doesn’t create one symlinked download of the files, it actually downloads to each and every synced folder duplicate copies. Not the end of the world now I understand that, but I think the primary use case people have is better served by the symlink concept than the multiple download destinations approach. For example: now, I have a choice - either I download to the “odrive/my drive/sync folder” location and don’t have these special system locations used at all (as you can’t symlink the other way without a lot of hassle) OR I sync to that system location and not to the “odrive/my drive/sync folder” location, which just leaves a .cloudf file in its place, so if I go to the “odrive/my drive” location I see a mixture of proper folders, and placeholders - this makes navigation cognitively heavy. Or I just have duplicate copies (which for a 400GB photo library is just not going to happen. Horrible experience.

There are other bugs, such as:

  • the menu bar icon not responding at all, taking away the only other way to interact with the app. Yep, I have to quit the app and finder extension processes directly. This is a complete and utter failure for UX.
  • CPU and memory hogging: As I’m trying to re-download a lot of stuff I get that this will be a factor, but the memory usage seems to have only an upward trajectory until killed… I see this is a common complaint in here… memory leak warning bells are ringing.
  • Not sure about this one due to the other bugs, but it also doesn’t seem to recognise existing local files that were there before I set up the app (I already had an offline copy of my files from previous sync tools).

There are other minor annoyances, but I think you get the idea.

Overall, I would really like this tool to work as advertised, because it is such an important part of my file management approach, and there are many things to like about what it should do. However, it just isn’t doing it right now. I am spending far too much of my time dealing with these issues - precisely the opposite of what I want from this tool. If your sync app doesn’t sync, then it shouldn’t go unresolved for a year and a half.

Of course, I may just be unlucky, and something is odd about my environment… however, I am running this on a Macbook Pro and iMac with the latest macOS installed on both (High Sierra has been out for around three months now). Not a particularly exotic / rare environment. I’m happy if you want to point me to answers to fix these issues permanently (not manual workarounds).

I will struggle on for a while until everything is fully synced and levelled out in case this is just a frustrating on-ramp challenge. If things continue to be this painful though, I will be asking for a full refund and going elsewhere. I’m sure that others are having similar experiences having seen this forum.

So, roadmap for 2018 should have “fix the damn bugs” as your top priority.
Seriously.


#2

Hi @damian2,
Thanks for taking the time to give us this feedback!

Looking through your list of items, I believe that every one is being hit by the next generation product, which we are trying to get out as fast as we can.

Recursive sync -
This is definitely an area that causes a lot of confusion/frustration. odrive will perform a recursive sync until it hits a certain type of exception (or multiple exceptions). It will then stop and not be remembered and retried. We have changed the architecture here so that it will never give up the complete operation, but it will fail certain files, if there are exceptions hit on those files that are considered “final”.

Finder extension and UX -
The nature of odrive placeholders creates some ambiguity in “roll-up” sync overlay representation, because the user gets to decide what they want local vs placeholder. Currently we show a checkmark if everything that needed to be synced to the remote storage has been synced. This means you can have a checkmark if you have some files that are still placeholders, as we still consider everything to be “in sync”, as per the odrive progressive sync philosophy. Of course, this can cause confusion and questions because the current folder state, with regards to locally cached vs placeholder, ends up being imprecise.

We have a separate UI in the new product that will give precise feedback on the state and status of files and folders. The Finder extension will still be there, but it is simplified, so it is not trying to do so much.

Sync to odrive -
You are correct that it is possible to have duplicates if you sync the items in the “sync to odrive” folder and the corresponding data in the default odrive folder. As you said, you would want to unsync/keep as placeholders the items in the default odrive folder and work out of the local folder. We decided against trying to manage this with symlinks. Symlinks can be very problematic, and can cause disastrous problems if they are used/manipulated incorrectly. They also cannot be monitored for changes the same way. The capabilities and implementation also varies across operating systems.

CPU/memory overhead and responsiveness -
If odrive is under load, you can start to see these effects. The number of queued/concurrent operations, the size of tracked data structures, and complexity of the configuration all play a part. If odrive is busy you can start to get latency in the UI responsiveness and higher overhead. This is something we have been focusing on for the next version. Of course, there will always be overhead, but we are trying to optimize the experience as much as we can.

odrive doesn’t have any knowledge of data that is outside of its configuration. Local data awareness/migration is something we’ve discussed, but we don’t have any plans for it, at this time.

There are definitely a number of areas to improve on, and the solutions for them are not trivial, which is why our current development cycle for the next gen has taken as long as it has. Keep in mind that we offer a no-questions-asked, full refund if you cancel your subscription within 30 days of purchase. If you find that the current offering isn’t going to meet your needs you can simply go to https://www.odrive.com/account/subscriptions to cancel.

Thanks, again, for the feedback @damian2. It is much appreciated.


#3

Thanks for the detailed and helpful response Tony, much appreciated.

It is great to hear you are actively trying to solve these problems, and I eagerly await the next release.

I am still waiting for the initial sync to finish to evaluate in a more stable context - hopefully this will happen within the 30 day window.

I can understand your reluctance to use symlinks, but hopefully you understand the use case I outlined and why the ‘concept’ of them works better to solve the use case than the current ‘concept’. Hopefully you can provide the solution a different way.

Good luck with the work on the next release.