New Insync version: 3.2.6

[Camille]

Release notes:

• Mac: Fix a crashing bug on macOS Big Sur
• Prevent deletions due to fluctuating network/external drives
• Linux: Fix install scripts for installers
• Linux: Improve checks for whether Insync is running
• Fix handling of insufficientFilePermissions error for Drive items

Windows 7 and later
macOS 10.13 (High Sierra and later)

Ubuntu (16.04 Xenial) , (18.04 Bionic) & (20.04 Focal)
Linux Mint (18.x) , (19.x) & (20.x)
Debian (8 Jessie) , (9 Stretch) & (10 Buster)
Fedora (27) , (28) , (29) & (30)

[Vladimir_Oka]

Just updated from 3.2.5 on Linux Mint 20.

Why does 3.2.6 need to scan through pretty much all the files - again?

I was fully synced up on 3.2.5. I see no reason for the new point-version to do a full rescan.

I hope it doesn’t do anything else stupid, either, now that I can’t go back to trusty 1.5.7 any more.

[tinywrkb]

I’m not sure on which release you started linking against gvfs and glib-networking libs but now that you do you really need to include those in the release tarball the same way you’re doing with other libs, that’s because users have been using your releases on other distros than intended (e.g. Arch Linux) and you’re linking against specific lib versions that are may or may not available in the user’s distro.

/usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so: undefined symbol: g_task_set_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so: undefined symbol: g_task_set_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so
/usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so: undefined symbol: g_task_set_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so: undefined symbol: g_date_time_format_iso8601
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so

Another issue that I noticed is that you’re not including the qt5-wayland shell integration plugins. For example, there’s no libxdg-shell-v6.so in PySide2/plugins. This means Insync can’t run as a native Wayland client and I need to force it to run through XWayland with QT_QPA_PLATFORM=xcb.

Also, can you give further details about this?

Linux: Improve checks for whether Insync is running

Are you still only using the Unix socket in /tmp for that? what about registering DBus name?

[POC]

On Fedora 32 I have to force a rescan to get anything to sync, as it doesn’t detect changes by itself. This has been happening since at least 3.2.3 if not earlier and I reported it at the time.

[Stuartbr]

Still no fix for the memory leaks for MacOS?

[Carlos_A_Iglesias]

Unfortunately, same problem than previously, insync starts to resync everything and takes 110% of CPU. I have to stop it to be able to work :(.

[mia]

Hey all-- can you send your logs.db and out.txt files to support@insynchq.com with the link to this post? We need to look into what’s causing Insync to re-scan/re-sync after you updated your version.

Thank you!

[Vladimir_Oka]

I’ll try to get hold of the logs. May take a few days. Where again do they reside?

I also noticed some redundant scan activity after a reboot (I rarely reboot so didn’t notice earlier).

Anyway, I’ll try, but unlikely before next week.

[mia]

Here you go: https://help.insynchq.com/en/articles/1834816-locating-the-log-files

[Vladimir_Oka]

@mia

Hi,

I just had an instance of an unnecessary apparent fulls re-scan. I logged out and logged back in for unrelated reasons and found Insync apparently doing a full re-scan. I didn’t wait for it to finish before zipping up the logs. Hopefully, that’s fine. If you require end of scan logs, too, I can try and provide those as well.

I e-mailed them as instructed.

Cheers,
Vladimir