New Insync version: 3.0.23

@Siamak @Konstantin_Boyandin Exact same behavior on my local install. But this affected me already before 1.5.7 - you can find multiple posts on this forum. My “workaround” is to always open the sub-folder in the GUI which then suddenly detects all folders and files and syncs them. It is so frustrating that this software is not able to deliver on it’s one core functionality that it is supposed to do well since more than a year.

I still put up with that because this manual workaround sadly is still more convenient than downloading/syncing files from the browser directly.

If there was any real alternative for Linux I would switch in a heartbeat. Sadly the alternatives do not (yet) support team shares.

Thank you for update!

In my case (Ubuntu 18.04) opening subfolder doesn’t help.

What’s also strange, many fully synced folders are displayed with yellow (‘partially synced’) icon, and there’s no obvious means to change that.

Pity the developers are too busy with more important tasks.

@Konstantin_Boyandin Do you open the subfolder in a file manager or do you use the Insync GUI? I have to open the Insync GUI and browse to the specific subfolder. Then it reloads the file structure from the online drive and downloads all missing files.

In my case (I have just checked that again):

  • when I add a file on a system (Ubuntu 18.04), Insync sends it to cloud (it appears in Web UI of Google Drive immediately)
  • when I open the folder containing the file in another system (also Ubuntu 18.04), the file appears in Insync file manager list, but not in actual local file system
  • I have to manually click “Sync” in Insync app file manager, to have file copied to local file system

I can’t fancy clicking “Sync” on multiple files every day, thus I use rsync.

(I wonder whether any of Insync developers actually read this, since my previous email exchange with them ended in smoke)

If this is happening for items in the root folder, check to make sure the sync option is set. Link to example Items created in cloud don't auto sync locally

Did you add this account as new so it reuploaded or as existing so you ended up with yellow check mark icons indicating ‘local-to-cloud file matching’ but not reuploaded? I think prior to 3.0.23 for me on windows, new items in folders with yellow check marks weren’t auto syncing but items in folders with green ones were.

Perhaps Insync team can clarify but I’m pretty sure yellow check marks are not indicating partial sync in the sense that some items contained aren’t synced. As I said above, pretty sure the yellow means that Insync has associated the local file with the cloud file but the file was not reuploaded, aka ‘local-to-cloud file matching’

@kyle There’s no ‘items created in cloud don’t auto sync locally’ option in my case (Linux version).

There’s ‘Sync new top-level cloud items automatically’ checkbox, and it’s checked.

Did you add this account as new so it reuploaded or as existing so you ended up with yellow check mark icons indicating file sync but not reuploaded?

Existing one. I have no fun re-syncing the entire Google Drive after every Insync upgrade.

When I place new file/create new folder in sync root, it gets propagated and is marked with green check. Consequently, files in it are synced from any device and gets propagated.

I wonder why some of my existing folders are marked with yellow check, and what exactly shall I do to make them sync again?

Correct, there is no setting called ‘items created in…’ that was a link to a screenshot showing the ‘Sync new top-level cloud…’ which actually appears to have moved in 3.0.23 to the settings icon next to ‘My Drive’

So it sounds like only items created in folders with a yellow check mark are not automatically downloaded locally by insync. This is pretty much the exact issue we had in windows which appears to have been fixed.

I asked about yellow checks in another thread:

The only way to change yellow icons to green is to unsync and then resync the item. I just tested and found that when I do so, the items are downloaded from the cloud (not uploaded to) and marked with green icon. The simplest way to change all items from yellow to green is to remove the account and re-add it as new so insync uploads/downloads files instead of doing the ‘local-to-cloud file matching’.

My observations based on user experience and various topics here, is that ‘local-to-cloud file matching’ (yellow icons) is not working correctly and leads to many problems including various sync errors (see Error AddCloudGDItemL(‘Unsupported file type:%r’, ‘?’)), most of which are solved by doing a full fresh sync.

@kyle Thanks for explanation. Well, I abhor fixing things in “traditional Windows” way (delete and reinstall), and I certainly hope I won’t need doing that after each upgrade.

Since I use file system level encryption with Google Drive (encfs and the like), there always will be plenty of “Unsupported file type” entities.

@kyle Do you have any explanation why syncing of sub-items will not work reliably? No yellow icons and not about new root folders… it happens with any content in sub-folders.

Re-syncing everything has no effect. The problem persists. I am affected since before 1.5.7 and was hoping that 3.x was any better. Sadly still the same issue.

Unfortunately, I’m not able to answer that. I’ve been using insync on multiple windows 7 and 10 machines for at least 3 years now with 6 free personal gdrives and one teams. insync 1.x worked pretty much flawlessly. I didn’t experience syncing issues until “upgrading” to 3.x. It has been rough to say the least but it seems to be functioning properly at the moment.

Can you provide more details regarding the installation? Which operating systems experience the issue, google cloud type (business, teams, personal), file types that fail to sync properly. Is your problem that items created locally get pushed to the cloud, but other machines aren’t automatically downloading the cloud files locally? Or is it that items created locally don’t get pushed to the cloud? Does this happen when renaming or changing existing files as well?

When you say “re-syncing” do you mean you manually unsynced and resynced or do you mean you removed the account and re-added as a new account rather than an exisitng account so it bypasses the 'local-to-cloud file matching’ entirely.

Might be better to start your own thread to discuss in more detail.

Thank you for taking your time writing that out.

Some more specific details:

  • I am using Ubuntu systems (several notebooks and desktops)
  • this bug is accompanying me since before 1.5.7 up to 3.0.23 since at least Ubuntu 18.10 (or 18.04) up to 19.04 and 19.10
  • I am using two G-Suite accounts (one private / free tier and one business G-Suite)
  • the problem is noticable on my business G-Suite account mainly with Team Shares
  • I do not use my private drive very much and I can not say much about my private Business share as I do not store much data there either
  • It’s happening definitely on Team Shares, funnily with files & folders I have created on e.g. my work PC and then my home PC does not sync the files down
  • the files are definitely available online and when opening the Insync GUI app and manually opening the affected sub-folder the app suddenly seems to re-fetch the folder/file info and starts syncing the missing data
  • it just does not automatically detect file/folder changes automatically which is quite annoying when looking e.g. through folders where we store customer files and you never can be sure if everything is in the folder or not when handling e.g. customer support requests - always have to manually check the folder online in parallel just to make sure I have all info available
  • when saying re-syncing I meant multiple strategies: using different Insync versions, removing and re-adding an account completely, removing selective sync on certain folders and then re-checking it later

I have reported the issues since last autumn in the forums and directly and received some first level support canned responses. Even though other users also report the issue in the 3.0.x beta threads on the forum the devs are painfully silent about this. I’ll wait a few versions longer and see if any Insync is addressing these comments at all.

Thanks for this extensive writeup. Great info here. I dug through the forum and found your previous threads going back to January. Posting links here in:

This should be a priority.

I have checked other Insync installations, using 3.0.23 (on Ubuntu).

Total removal (app, its settings, synced folder) and re-installation and re-sync on all devices seem to help. So far, no “yellow checks” and new files seem to propagate normally.

Thanks. I hope I won’t have to repeat total re-sync every app upgrade - it’s both time- and traffic-consuming.

Hello,

Just a quick report: I have upgraded from 3.0.22 and everything seems to be working well. The new features are interesting, thanks.

I’m using Xubuntu 16.04.5.

The only downside is that I still can’t install the insync-thunar package because of some conflict, but it’s not that important for me. The console output is below:

$ sudo apt-get install insync-thunar
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 insync-thunar : Depends: thunarx-python but it is not installable
E: Unable to correct problems, you have held broken packages.

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