New Insync version: 3.0.23

The thunar-insync plugin for insync3 does not work at all so far … :frowning_face:
I am trying to escalate this problem, but the insync developers internal priority is obviously very low, so … !!!

3.0.23.40579-buster (Debian)

Not sure why the mandatory folder “Google Drive” is needed, i should be able to use any folder for syncing Google Drive…

I don’t think it is needed. I sync to a differently named folder. I remember being able to choose one at first installation and then the upgrades of Insync just picked it up. Can’t remember the exact steps, but it’s definitely possible. This on Linux Mint, various versions and Insync 1.5.7 and 3.0.2x (and back to 1.5.7, unfortunately).

Running Xubuntu 18.04 LTS. Kernel: 4.15.0-66-generic x86_64 bits: 64 Desktop: Xfce 4.12.3 Distro: Ubuntu 18.04.3 LTS

Insync 3.0.23.40579 installed along with insync-thunar.

Two BIG problems:
1- No contextual menu support for insync in thunar.
2- Syncing across computers is BROKEN. Icons are showing folders are NOT synced when they actually are. See Employment folder:
EmploymentFolder_2019-11-07_08-17-53

And, files added on one computer are NOT being automatically synced with the other computer. See Employee folder:
EmployeeFolder_2019-11-07_08-20-00
If I want the files to sync on the second computer, I need to manually click on the sync icon/button for that file.

Previously, all files and folders inside the top level sync folder would sync between computers automatically.

This problem is a dealbreaker, as I need files to sync between computers automatically.

The first problem has existed since I first installed the 3 series of insync. The syncing problems seem to be new, as the earlier versions of series 3 seemed to restore automatic syncing after the first or second upgrade. In other words, automatic syncing has suddenly disappeared from series 3 with this latest version.

Here is what I see when I use insync start --no-daemon:

$ insync start --no-daemon

(insync:16172): dbind-WARNING : 08:42:17.140: Couldn’t register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
libpng warning: iCCP: known incorrect sRGB profile
INFO 2019-11-07 08:42:19,282 [mainlogs:_log_run:92] Core(app_version=3.0.23.40579, platform=Linux-x86_64-ubuntu/18.04) initialized
WebEngineContext used before QtWebEngine::initialize() or OpenGL context creation failed.
WARNING 2019-11-07 08:42:19,414 [base_events:_run_once:1771] Executing <Task pending coro=<init() running at ideskcore/core.py:113> wait_for=<Task pending coro=<SettingsMain._load_settings() running at ideskcore/mainsettings.py:141> cb=[_log_tb_after_delay() at ideskasync/coreloop.py:302, <TaskWakeupMethWrapper object at 0x7f2c32dbb3d8>()] created at ideskcore/mainsettings.py:123> cb=[_log_tb_after_delay() at ideskasync/coreloop.py:302, _chain_future.._call_set_state() at asyncio/futures.py:355] created at asyncio/events.py:88> took 0.453 seconds
INFO 2019-11-07 08:42:21,272 [fswatcher:_start:38] LinuxFSWatcher._start
INFO 2019-11-07 08:42:21,273 [inotify_manager:_pull_loop:307] Inotify loop enter
INFO 2019-11-07 08:42:21,278 [fswatcher:watch:53] watch origin: /home/
/Team Drives/**
INFO 2019-11-07 08:42:21,279 [insync:start_core:44] core started
INFO 2019-11-07 08:42:21,280 [unix_socket_server:start:46] unix socket server thread start
INFO 2019-11-07 08:42:21,288 [fswatcher:watch:53] watch origin: /home//
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile

Don’t know if it’s a feasible strategy for you, but I went round the first 3.0.2x release (20? 22?) spent time re-syncing (shouldn’t have happened)

Went back to 1.5.7 (with little syncing, thankfully).

Gave first 3.0.23.x a go and luckily realised before syncing gigs that it’s still broken.

Finally went back to 1.5.7.

Waiting for version Z to drop that will actually work. Following the forums here to judge if the problems have been largely fixed but judging from the recent experience will be on 1.5.7 for a very long time to come…

This is one of the most shoddy major version FUBARs in living memory.

The yellow check icons don’t mean that the folder isn’t synced. They simply mean that Insync completed local file to cloud matching without actual data transfer which is what happens in 3.x when you choose to upgrade an existing installation rather than adding an account as new. If it makes you feel better, you can manually unsync and resync everything to get green check icons. Alternatively you can remove the account and add it as new so items are retransferred.

The context menu functionality in 3.x is yet to implemented for any operating system.

If 1.5.7 works for you, then use it. Insync team has stated this week that the issue you’re having where files aren’t automatically synced from the cloud to local machines is because Insync team has literally not implemented that functionality in 3.x. It’s not a bug, it’s actually a missing core feature that they stated will be implemented in 3.0.25. No joke.

Insync team has stated this week that the issue you’re having where files aren’t automatically synced from the cloud to local machines is because Insync team has literally not implemented that functionality in 3.x. It’s not a bug, it’s actually a missing core feature that they stated will be implemented in 3.0.25. No joke.

Which means the current latest release is a joke.

If it can’t sync from cloud to local then what’s the point? When I create a file in the cloud (or other synced machine) I expect it to appear wherever the containing folder is synced.

Releasing Insync without this functionality is pointless, really. It’s not “rough around the edges” it’s incomplete. They should have delayed the release until all expected functionality is present. At least the core functionality that was already present in 1.5.7.

As it is, they wasted a lot of people’s time and lost a lot of goodwill in the process. A shame.

1 Like

How did you install isync-thunar package on Ubuntu 18.04 ??? There is always the following error message:

The following packages have unmet dependencies:
 insync-thunar : Depends: thunarx-python but it is not installable

bacause thunarx-python is not for Ubuntu 18.04 available.

1-SYNC PROBLEMS
So, the 3 series significantly changed syncing behavior from 1.5 series. That should have been better explained. I went through the materials that were available and actually delayed upgrading to 3 until I saw that initial kinks were worked out.

2-CONTEXT MENU
Your upgrade notice actually says that there is thunar intergration in the current version (see second to last bullet point).
Thunar_2019-11-08_08-27-00

And, I have thunarx-python installed.

Look, I understand a major re-write of software is difficult. Just explain what is happening with some transparency. I get it: the change in syncing behavior from 1.5 to 3 adds more control, but it needs to be better explained.

Hi. I’m on Prime license, and I’ve just noticed that I have access to team drives. But I haven’t bought a license for it… Does it mean good news for me, or a bug? :slight_smile:

Here is my write-up on how to FIX the changes to automatic syncing in v3 (sorry for not posting the explanation here, but I did not feel up to writing up the explanation twice):

Thanks Vincent!

Very useful guide.

One question: when you say procedure has to be repeated for every folder, does it literally mean every leaf folder, or will doing it for a tree root propagate to all children? Also, even if yes, will new children inherit this? Or is it the case of every folder every time, new subfolders included, and new children, too? If the latter then this is so unreliable (depends on iron self-discipline) that it is still better to stay on 1.5.7.

Thanks for the write-up! I would add that there is hope that from 3.0.25 on the files will get synced automatically between computers again. At least someone said the team was saying that. So hopefully it will be re-implemented some day.

My experience up to 3.0.20-ish was a bit different. I just had to browse to the not fully synced folder in the Insync GUI and when there were files in the Cloud but not locally it suddenly refreshed the folder structure and automatically synced all elements within. Which means I never had to press any additional “sync” button. Maybe it has changed in the last few versions. Will keep my eyes open and update if my experience changes.

I do not understand this. You have Xubuntu 18.04? Am I right? As you can see at this link: https://packages.ubuntu.com/search?keywords=thunarx-python

Thunarx-python package od not available for Ubuntu 18.04 (bionic) at all. This is may be the reason why XFCE Insync thunar plugin (insync-thunar_3.0.23.40579_all.deb … available from https://www.insynchq.com/downloads) does not work.

So, you are using thunarx-python v0.3.0.1 from some PPA repo, but this version is not definitely compatible with Ubuntu 18.04. And this is the reason why context menu at XFCE still does not work.

From my point of view Insync developers does not really test the insync-thunar plugin on current LTS version of Ubuntu (+ all ubuntu based distros).

Any comments?

You can select more than one folder for syncing. And, so far it seems to stick once full sync is turned out for the folder.

What is happening here is a change in default behavior: In 1.5, full, automatic syncing was the default. Now, with v3, manual sync is the default for those upgrading to v3.

In regards to changes in this behavior, I think wolfi may be right about v3 series changing sometime among the various versions. The insync folks should provide these details.

I have thunarx-python because I have been using Xubuntu since 10.10 (or maybe earlier). Google the ubuntu forums about re-activating prior repositories. Or, you can manually download the .DEB and add the file using gdebi. It looks like thunarx-python was last included in the regular repositories with 18.04.

And, it appears from the link you provide that thunarx is part of eoan, which is 19.10.

For installing specific software, I like synaptic, which I discuss briefly in https://linuxatty.wordpress.com/2018/07/23/review-galago-pro-from-system-76-and-xubuntu-18-04-bionic-beaver/.

The re-activating of prior repositories is generally very bad idea. You can completely destroy your current system by this way!!! Moreover, as you see, the thunar plugin does not work on your system, too. Even in a case, you have installed thunarx-python package from any unofficial repo.

So once again, thunarx-python is available only for Ubuntu 19.10 (NOT for 18.04 !!!) from official Ubuntu repositories. Any other unofficial way to install Ubuntu 19.10 or any other thunarx-python package on prior Ubuntu releases is very dangerous.

Here is the 18.04 repository for thunarx:

https://packages.ubuntu.com/bionic/libthunarx-2-0

This is completely different library, which has nothing to do with thunarx-python package!!!

Yes, you’re right. Libthunarx is what allows thunarx-python to work.

You should try adding the deb for thunarx-python manually from 19.10 or a version older than 18.04.

But, that option will only fix the integration with thunar problem with v1.5. The v3 series of insync has no integration with thunar at the moment, even if you have thunarx-python installed.

Part of the good and bad with Linux is having more control over your system. Manually installing a deb file is a small step, and gdebi will check for incompatibilities. And, allows for easy rollback (i.e., uninstall) if problems do arise.