New Insync version: 1.2.10

This is a hotfix release for 1.2.9. It is for Linux only.

Release notes:

  • (Headless Linux) Fixed issue when moving Insync folder.
  • (Linux) Reverted a change in 1.2.8 that caused some users to experience very slow syncing.

Ubuntu 13.10 and older: 64 bit, <a href="http://s.insynchq.com/builds/insync_1.2.10.35142-precise_i386.deb"32 bit headless: 64 bit, 32 bit
Ubuntu 14.04 and newer: 64 bit, <a href="http://s.insynchq.com/builds/insync_1.2.10.35142-trusty_i386.deb"32 bit
Debian: 64 bit, 32 bit headless: 64 bit, 32 bit
Fedora 19 and older: 64 bit, 32 bit headless: 64 bit, 32 bit
Fedora 20 and newer: 64 bit, 32 bit
Portable: 64 bit, 32 bit

Please help test.

Thanks!

Hello!!

I’d had problems with previous version, now are solved. Thanks for the really quick fix.

Very best regards!! :smile:

Since upgrading to 1.2.9 yesterday, I got 71 error messages that, as far as I can see, concern very old files that I have not been busy with for years. Retry does not help. Other, new, files, get synced. I hoped that upgrading to 1.2.10 would solve these issues, but it didn’t. Speed seems improved, though. Any hints?

I just got the update and it is 1.2.10 on Mint 17 and it is duplicating my files in some folders, and erroring in some folders.

example:
Thai Basil Chicken Curry (2).gddoc
Thai Basil Chicken Curry.gddoc
Thai Peanut Sause (2).gddoc
Thai Peanut Sause.gddoc
Thai Shrimp Cake (2).gddoc
Thai Shrimp Cake.gddoc

In my case, it is also related to .gddoc files only. The rest seems fine.

@Maarten: @Netmorin: Since 1.2.8, Insync tries to create a copy of the Google format file corresponding to the .gddoc, .gdsheet etc. files that were added locally. Previously, Insync would just ignore those files. What error message are you getting? Is it: “Can’t process - x: file not found”? If so, the corresponding Google format files to those .gddoc files must not exist in your Google Drive anymore (could have been unshared or permanently deleted), that’s why Insync can’t create a copy of those files.

@Netmorin: Could you send to us Insync logs at support@insynchq.com so that we could look at the cause of those duplicates? Here is how to locate the log files: How to find the log files

Thanks

@dipesh: yes it is the file not found message. And indeed I checked various files and they do not exist online anymore. This is because in an early stage of using Insync, I experimented with moving directories from one account to another. This worked, except for .gddoc files. But what is the solution? How can I force that they will be created in the cloud? That would solve the issue for me.

Fixed now, by removing the files.

Ubuntu-MATE 15.04 , Insync 1.2.10

Since the upgrade, when I click ‘Go to Folder’ , it instead loads ‘/tmp’ with a error dialog ‘fileXXXXX could not be found. It may have been removed.’ There is no way now to reach the Google Drive folder except through manually browsing there via the file manager (Caja)

Very annoying, syncing seems to work fine though.

Log file below:
Got bus address: “unix:abstract=/tmp/dbus-ZpVYQqMpeg,guid=cb5d92fd84c3cdb6c9137437554ed685”
Connected to accessibility bus at: “unix:abstract=/tmp/dbus-ZpVYQqMpeg,guid=cb5d92fd84c3cdb6c9137437554ed685”
Registered DEC: true
Registered event listener change listener: true
SpellCheck: Language = “en_US”
QSpiAccessible::accessibleEvent not handled: “8008” obj: QObject(0x0) " invalid interface!"
QSpiAccessible::accessibleEvent not handled: “8008” obj: QObject(0x0) " invalid interface!"
Got bus address: “unix:abstract=/tmp/dbus-nbHyRGk7c0,guid=d205f7d93581d41830ad19b9554ed9f8”
Connected to accessibility bus at: “unix:abstract=/tmp/dbus-nbHyRGk7c0,guid=d205f7d93581d41830ad19b9554ed9f8”
Registered DEC: true
Registered event listener change listener: true
Got bus address: “unix:abstract=/tmp/dbus-XkEO9K6gmp,guid=6e16b4eb4848132b99bd3067554f571c”
Connected to accessibility bus at: “unix:abstract=/tmp/dbus-XkEO9K6gmp,guid=6e16b4eb4848132b99bd3067554f571c”
Registered DEC: true
Registered event listener change listener: true
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x21eacd0) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x21eacd0) “”
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x21eacd0) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x21eacd0) “”
Created new window in existing browser session.
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x21eacd0) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x21eacd0) “”
Got bus address: “unix:abstract=/tmp/dbus-RlZubDZevs,guid=05d9c2b145c4400a6ec4eb44554fa76d”
Connected to accessibility bus at: “unix:abstract=/tmp/dbus-RlZubDZevs,guid=05d9c2b145c4400a6ec4eb44554fa76d”
Registered DEC: true
Registered event listener change listener: true
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “6” obj: QMenu(0x3097e20) “”
QSpiAccessible::accessibleEvent not handled: “7” obj: QMenu(0x3097e20) “”
Created new window in existing browser session.

@drvortex Please send your logs to support@insynchq.com as well, thanks.

Any chance this gets packaged for Arch soon ?!

I’m currently running ver. 1.2.7 (latest available from AUR) and it seems to no longer sync properly…

Cheers,

Julien

@jumaxotl We don’t maintain Insync’s AUR. Please contact the AUR’s maintainer xzy3186 instead. Apologies.

@Maarlen_Wisse: You can’t copy a Google Document cross accounts by copying .gddoc file from one account to another locally unless the account to which the .gddoc file has been copied to, also has access to the corresponding Google Document (shared file/public file).

.gddoc, .gdsheet etc. files only contain information such as file id and url of the corresponding Google format file. These do not contain actual contents of the Google document, spreadsheet etc. You can think of these as shortcuts.

When you manually add a .gddoc, .gdsheet etc. in the Insync folder, Insync tries to create a copy of the corresponding Google file on Google Drive web but since in your case the another account does not have access to that file, it errs out saying file not found.

If these files still exist in the original account, share those files from that account to the account, which you copied those files to. Then, retry all those errors.

Thanks

Sorry for the wait, I’m emailing in the log.db now. Not sure what my errors were, they are gone now. But, those duplicates remain. I run Linux, I think I can script a way to remove them.

When running on Fedora 22, I’m getting a libpango error when it tries to show the tray icon (this occurred on 1.2.8 and 1.2.9 as well). For example:

[mhicks@host~] $ insync start --no-daemon
./insync: symbol lookup error: /lib64/libpangoft2-1.0.so.0: undefined symbol: FcWeightFromOpenType

Then not showing tray icon:

[mhicks@host ~] $ insync start --no-daemon --headless
which: no kreadconfig in (…)
INFO 2015-05-15 07:02:11,775 [init:info:1612] insync version: 1.2.10.35142
INFO 2015-05-15 07:02:11,776 [init:info:1612] client created <ideskmain.client.Client object at 0x243e990>
INFO 2015-05-15 07:02:11,777 [init:info:1612] unix socket server thread start
INFO 2015-05-15 07:02:11,777 [init:info:1612] starting client

Would it be possible to build against the latest pango for Fedora 22 to see if this goes away? On my system, the version installed is:

[mhicks@host ~] $ rpm -q pango
pango-1.36.8-2.fc22.x86_64
pango-1.36.8-2.fc22.i686

Thanks!

@matthicksj Does this prevent the tray icon from appearing?

@lpugoy I’m seeing the same behaviour as @matthicksj. It prevents the icon from appearing, but nautilus plugin works as expected.

Just a side note. Updating to the newest release (1.2.11.35149-fc20) does not solve the issue.

It actually keeps Insync from starting altogether:

[mhicks@localhost ~] $ insync start
[mhicks@localhost ~] $ ps -ef | grep insync
mhicks 27865 19564 0 08:58 pts/0 00:00:00 grep --color=auto insync

Versus running with --headless

[mhicks@localhost ~] $ insync start --headless
[mhicks@localhost ~] $ ps -ef | grep insync
mhicks 2862 1 63 08:58 ? 00:00:01 ./insync start --headless
mhicks 3633 19564 0 08:58 pts/0 00:00:00 grep --color=auto insync

1 Like