Sync on Demand? insync doesn't deliver on its promises?


#1

Alright, so I set up a fresh Linux install, and am looking for good Google Drive client.

First, where am I coming from? I’m also using Google Drive File Stream (DFS) on a Mac in parallel. Any client I’m using must have the core feature of this reference client.

Looking at the website of insync, you promise to be just that. With the table, you openly claim “We’re as good as DFS and better” (the same for Backup&Sync, but that isn’t hard to achieve).

So, what is THE core feature of DFS to me? It’s what I’d translate to the entry in your table called “Sync on Demand”. After starting my insync trial yesterday, I couldn’t find that features. So there’s three options:

  1. You need to manually turn on that feature and I haven’t found it (in which case my question would be: where do I find it?)
  2. insync defines the feature differently than I do and the functionality is different (and inferior) to DFS
  3. The feature doesn’t exist for the Linux version of insync. In which case my question would be: why? On Mac and Win, DFS is free and pretty good, your main USP is availability on Linux.

If 1. is the case, thanks in advance for your help. If 2. or 3. are the case, insync is completely worthless for me at this point and I’ll be better off writing my own client. I’m happy to pay for software and if I don’t need to write my own solution, but when I pay, it has to deliver.

Now, to explain, what is “Sync on Demand” to me?

Here’s what DFS (on Mac) does:

  • It mounts Google Drive. Probably using FUSE or something like that, but it’s a mounted volume.
  • When I list the contents of this volume, I see all my files and the entire directory structure (insync doesn’t do that, the folder is empty)
  • None of the files are downloaded at this point (neither for insync, that’s why they don’t show, the difference is that they show for DFS)
  • In Finder, besides every file or folder on the mounted volume, there’s a small icon, either a little cloud symbol or a green checkmark. Cloud symbol means “this file isn’t cached locally, so not available offline”, green checkmark means “this file is cached locally, you can access it offline”.
  • When I open an uncached file, the following happens:
    • DFS downloads it from Google Drive
    • It is opened
    • If I change anything in the file, once I save it’s synced to Google Drive, same as a file that is cached (for all intents and purposes, it IS a cached file for the time it is open)
    • When I close it (and the file is synced) it is eventually deleted from the local cache again
    • all this is done automatically, I don’t have to tell DFS “Please download this file, so I can open it”. As long as I have a decent internet connection, I notice no difference in my workflow than with the file synced to disk.
  • In the finder context menu, I have options to cache/uncache files and folders
  • This feature is essential to me, since I don’t want so sync all (or large parts of) my Google Drive (it’s larger than the available disk space). I want to cache some files, but >90% of the files I only want to access remotely. And I don’t want the hassle of managing this, I want this file system layer which does the downloading and syncing for me.

That is what I consider “Sync on Demand”, and so far, I haven’t found it in insync? Am I wrong? Or is insync in fact inferior to DFS?

I looked into writing my own client before I discovered insync and decided to give it a shot, and most of the features seem fairly easy to realize, the most tricky part being the eyecandy stuff (symbols in file explorer whether file is cached) and the context menu cache/uncache. Mounting Google Drive in a FUSE and having a local file cache is a bit of work, obviously, but seems not that difficult.


#2

Hi @yldf. Thanks for reaching out!

After installing Insync on Linux, do you see the Insync icon on your system tray or the GUI? Sometimes there are extra installation steps (install sni-qt) for the GUI to appear on Linux machines. We have a guide for that here: https://help.insynchq.com/installation-on-windows-linux-and-macos/linux-getting-your-gui-to-show-up – We hate that this is necessary in some cases, and we’re looking to fix that!

The GUI is where the “sync-on-demand” happens and where you can access other Insync features. You’ll be able to see your Google Drive files and choose the files/folders you want to sync from there. Looks like this:

We don’t use mounted volumes. Instead, you can use a central Insync sync folder and/or choose local folders to sync to.

Aside from seeing synced and cloud files on the Insync app, synced files will appear on your file manager. Changes are automatically synced, and you should also see icons, like a green checkmark, to indicate synced files.

p.s. we do allow for Insync to be controlled via CLI, here’s a guide on commands.


#3

Ok, thanks for the fast reply, that was my suspicion. So, in this feature, insync is way inferior to DFS.

The fact that I have to use the insync GUI to sync on demand is a dealbreaker for me.

Consider the following use case:

  • You have some file you open with some editor for this type of files. That file is on Google Drive, but you don’t want it to be permanently synced to your disk (due to disk space constraints).
  • You have the file in the history of the editor, so there’s some “Recently opened” feature.
  • You click on the file in recently opened, and it will fail because the file isn’t synced.
  • With the behaviour implemented in DFS, the file would be downloaded and opened.

Another use case:

  • You have files you don’t want synced on google drive and you want to open them programmatically or from the command line
  • What you would need to do, is use some CLI for insync (which might exist) to sync the file, before you can open it
  • Your software would need to support that

Having to go to the insync GUI, find the file there, and click it - that is just an unnecessarily complicated workflow. So is issuing an extra command to sync the file before opening it.

Of course, one workaround would be to write a FUSE that decides whether a file is synced or not, and if not have insync sync it. But quite frankly, that’s not much less work than downloading it directly from Google…

I think you missed the point on what Drive File Stream is good for by deciding against this behaviour (or you started development before DFS was released and changing your architecture to a different model is too complicated).

In my opinion, the feature you’re describing is not a sync on demand feature at all, but an explicit sync triggered by the user, not when access to the file is requested (which is what I call “on demand”).

Again, this missing feature is a dealbreaker for me. I think I’m gonna write my own client then…


#4

You’re right @yldf, Insync doesn’t work well for those use-cases. We’re looking for where to take Insync, how to improve the app, so we do appreciate the input especially since you’re coming from DFS on Mac.

We can learn a lot from your use of Google Drive and requirements of sync clients. Would you be open to answering more questions from us? It could lead to an Insync that checks off your needs! :grin:

(cc’ing @jbec, our Customer Advocate)


#5

Sure, go ahead! I’m happy to help.


#6

I agree that what Insync is doing is just selective sync, and is nowhere near Drive File Stream. Saying it is is a bit of false promise/advertisement.

But

Are you sure you really want to do that? Sync clients are not that simple to write.
Have you tried things like google-drive-ocamlfuse and ExpanDrive?


#7

Well, wanting to do that is a bit of an overstatement. But in lack of a sensible alternative I really have no choice.

google-drive-ocamlfuse is remote-only and has no offline caching. ExpanDrive is Win and Mac only, they’re saying they’re working on a Linux version, though. On Win or Mac, there’s no point in a third-party client when DFS does its job. Frankly, other than combination with other cloud storage options, I see no USP for such a software except on Linux where Google doesn’t provide their clients.

I had a look at Google’s REST API for Google Drive, and this seems doable. However, to put things into perspective, I’m not talking about a production-quality client. There would be no GUI whatsoever, in the first iteration I wouldn’t have fancy stuff, just syncing files, without handling of any issues (like file open on two clients, both issue an update -> conflict), no testing on other systems than my own, nothing for distribution to users. The effort for such a client is still measurable, but it’s far less work than something you publish.


#8

100% agree.

Insync’s implementation of “Sync on demand” isn’t good enough. Having to use the Insync GUI to navigate files is horrible.

Users need to be able to sync on demand via Windows File Explorer - not a third party GUI.

Dropbox and Drive File Stream do a pretty good job of allowing uses to sync on demand or configure files to be available offline.