New Insync version 3.3.4

hola! thanks for the acknowledgement!

what do you mean by “same base folder for sync across each of the platforms”? can you give an example of what you are trying to solve?


I have two machines, one with dual-boot Win/Lin and the other is a 3-way (Win/Lin/Hackintosh). Both machines have a common ‘data’ drive which is used to store data for common access, and also is home to my ‘Google Drive’ folder.

In my case, the external volume is NTFS/Bitlocker and I use dislocker with FUSE to make the drive available under Linux and macOS.

I’d really like to have InSync under Win/Lin/macOS working with that single ‘Google Drive’ folder on that shared drive, to avoid wasting disk space, and without getting duplicate files (e.g. (1), (2) copies) and so on. It’s one of the key advantages over the official client (Google Backup/Sync refuses to work with non-mac file system drives; there is no client for Linux).


I see build 40916 appeared in Linux Mint repositories today.

What are the changes between 40914, linked above as the first release of 3.3.4, and the 40916?

Hi @Vladimir_Oka!

We made further changes to the in-app and systray icons. On 40914, the Errors tab displayed a blue dot with no systray icon. We reverted it to the old behavior in 40916-- errors will show a red ! both in-app and on the systray to alert the users accordingly. :slight_smile:

Thanks, @miamoran!

I did notice the blue dot but didn’t think much of it. Still, the change is probably for the better. :slight_smile:

I noticed the two ‘like’ responses. Does that mean it might be something InSync could consider in the near-ish future? Any remaining questions about the feature request?

yes, dual boot support is being considered, thanks!

1 Like

Insync simply stopped automatically syncing as of a few days ago.

We are discussing this issue here: Onedrive not syncing on Linux after upgrade


Glad to see insync team is constantly working on the client. Not sure has it been fixed with this version or earlier but I’m glad that memory consumption has greatly reduced from 180mb to 80mb
Thanks team!

1 Like

I see build 40916 has become available for Windows. Is it expected for Linux, too? What’s the changelog?

Hi! You can fetch the update from our repos. The early releases on forums may or may not be the final version. Good eye as always, @Vladimir_Oka :slight_smile:

If you want to get updates on the latest release in the repos then put this in urlwatch and you’ll know when the Debian Buster repo is updated.

name: "pkg/insync: debian buster repo"
url: ""
ignore_cached: true
  - grep: 'Version'
  - shellpipe: 'sed -e "1 s/\(^.*$\)/Desktop: \1/" -e "2 s/\(^.*$\)/Headless: \1/"'
1 Like

Thank you, @tinywrkb!

@miamoran Thanks for the tip. I do have my update manager set to look. It’s just that it wasn’t available yet when I saw it on my Windows machine.

BTW, I am still seeing the icon greying out after a while (Linux Mint 20.1). A long while to be fair, but I tend to have my (Linux) machines on all the time so I notice. And I can’t put a time estimate on it but it feels like a regular occurrence. A restart of Insync sorts it out for a while.

Minor but annoying as I often take it as a sign of my network connection begin down so I faff around until I realise it’s just Insync playing up.

Having said all this, the grey icon appears quite quickly now, but it sort of blinks in and out (changing to green check/blue syncing as required) every few minutes or so. The network connection is on and stable.

Could you send your logs.db and out.txt files to @Vladimir_Oka? I’ll have our engineers check for any timeouts or network issues on Insync’s end. Thank you!

@miamoran I’ve now updated to 3.3.5 but will continue to keep an eye on this and will send logs if I think it’s happening again. Seems stable so far (since yesterday). Although the (public) 3.3.5 changelog didn’t contain anything that would point to this kind of improvement.

1 Like

I’m just about to start evaluating Insync, and I was fully expecting to do exactly that. Why doesn’t it work? What happens when you point at the same folder with the second boot OS?

Typically, you get duplicate files ending with (2) or similar in the filename. Speculating, I think the sync DB (held locally) is using OS-specific file path representations so that something like c:\Google Drive\bob.txt appears different to /Volumes/Data/Google Drive/bob.txt which is also considered different to /mnt/Data/Google Drive/bob.txt. When the sync DB is considered on the other system, it cannot understand the existing file definitions as the file system mapping is completely different.

Again, I’m only guessing, but it seems to be the cause based on how I saw duplicates of the files piling up. It would explain why the tool doesn’t see them as the same and you get an intermix of duplicates all over the place. Assuming my guess is good, I would hope that any fix would cause the tool to no longer use the OS specific representations but a native hierarchical representation that can be reconciled with the OS representation when walking the filesystem.

I could very easily be wrong. I wouldn’t be surprised :slight_smile:

1 Like

Sigh. OK, thanks. I’ll go back to looking for a program that does what I need. I’ve actually had pretty good luck with Backup and Sync on that front. It’s the desktop.ini and _icon and _icon(1) and ._somefilename and so forth that are making me crazy. I’m here for the exclude file.