[edit 2]
At least the re-scan seems to have been relatively quick this time. Still unnecessary, though, methinks…
[/edit]
[edit 1]
I actually sent logs in response to 3.2.5 topic:
[/edit]
Updated from 3.2.6 and once 3.2.7 started, after a little while, it started a full re-scan.
Similar to what I experienced with 3.2.6 with just logging out of the Linux session and logging back in (not logging out of Insync).
I sent some logs linked to the 3.2.6 topic (at request at @mia).
I guess I could gather some logs now, too, but it’s probably redundant as changelog does not point to anything that might have affected this behaviour.
Anyway, please someone have a look as it is ridiculous to have Insync spend hours re-scanning so often!
Thank you for adding the Qt5 Wayland shell extensions in this release. This works nicely on Arch Linux and Sway compositor, running Insync as a native Wayland client for the first time.
For some reason, I couldn’t get it to work in Flatpak, the only error I’m seeing is with strace and it’s a failure to allocate memory via a mincore() call.
edit: I know what the problem with Flatpak and why it works in Arch Linux. Basically when running under Wayland, Insync tries to use the Wayland EGL backend but something not working correctly.
On Arch Linux it fails early, I’m not sure why but then it falls back to software rendering of the Wayland client.
When using Flatpak, Insync manages to go further and start talking to the GPU, requesting resources but then it fails (looks like memory allocation issue) and because it already started using the EGL Wayland backend it can’t fall back to software rendering.
The workaround I’m using with Flatpak to bypass this issue is to not give access to the GPU (/dev/dri) and then Insync just falls back to software rendering.
edit2: I think the issue is that a mismatch between some of the libs that are packaged with Insync and the host system is causing this issue. It looks like I got it to work with the Wayland EGL backend after dropping a few libs.
edit3: I removed libGL{X,dispatch}.so* and now the Wayland EGL backend seems to work.
I’ve been having all sorts of problems syncing Google Drive for a few weeks now. I’m running Fedora 32 (Wayland). It seems to get stuck on some random file or directory - usually an old directory filled with PDFs that has not been changed in years - and my CPU gets pinned.
I have a possibly stupid question - how/why does the Windowing engine whether it be X or Wayland figure so heavily? I would assume the sync’ing engine is headless. The GUI is rather simple. What would/should it have to do with syncing operations?
Exclude folder option has been removed or didn’t work in this version… upgraded and the software and it proceeded to delete a bunch of folders that were suppose to be excluded. Why do you think software has the right to delete files? If something is “excluded” and not in the cloud ignore it - don’t delete the local copy!!!
I could restore some from the recycle bin but others were just gone… this isn’t user error, I have read all documentation and followed the support… this is a major functionality issue or bug.
These files are part of my job and I expect more from a company handling files like this!
Very PO-ed… created this account to warn other people…
Uninstalled there is no other option by go back to google drive at this point.
I am giving up, and moving to the google app, at least on my Mac…
There are just too many bugs and things like the huge memory leak have not yet been fixed after months.
I may give another chance to insync when a usable version will be released, but for now it is really a mess
stuck on 3.2.6 because of this error when running apt-get update:
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://apt.insync.io/ubuntu focal InRelease: The following signatures were invalid: EXPKEYSIG A684470CACCAF35C Insynchq Inc services@insynchq.com