Hi @POC,
Just to clarify, did you migrate from 1.5 to 3?
Experienced something like this myself (I’m on Ubuntu 18.04) and Insync should get back to normal usability after the initial file scan and match.
Hi @Junior_Tonny,
We’ll look into it. But for now, I think you can submit a request with the AUR so that they can support and maintain Insync 
No duplicates. I thought it might have been matching, but the length of the progress made it look like they were being uploaded, and there was no wording to suggest otherwise, that I can remember.
Looks like all is well, it just took a while.
1 Like
Hot tip: if you’re on a Debian-based system (e.g. Ubuntu) and attempting to install the 3.0.11 package fails with an error to the effect of “package is in a very bad inconsistent state”, a sudo dpkg --remove --force-remove-reinstreq insync should get you back to a clean state, from which you can either reinstall your original 1.5.x release or attempt the new package once again.
(For some reason my upgrade failed the first time and I had to try it a second time before it ran to completion.)
1 Like
If I try to add a OneDrive account, I get as far as authenticating against the proper MS login, but my insync client seems unaware that anything has happened. Any suggestions?
P.S.: I can confirm that upgrading from 1.5.7 to 3.0.11 triggered a resync of everything, which is – needless to say – taking some time.
I was previously using 1.5. I installed 3 using ‘dnf’, then followed the re-authentication procedure and selected the same Drive and local folders. As far as I can tell, the files are not being duplicated (my Drive usage has not gone up) but it’s still working after more than 24 hours and using bandwidth on my upload link. The insync window lists a changing bunch of files and shows progress bars. None of these files have changed recently but insync doesn’t seem to realise this.
Luckily I don’t have a usage cap or this would be more than merely annoying.
Hi @POC,
Yikes!
Can you let me know how big your directory is? How many files are in your directory?
$ du -sh GDrive
339G GDrive
$ du GDrive|wc -l
1764
Note that the bandwidth being used in in the 2-3Mbps range. My Internet connection is rated at 80Mbps and usually gets pretty close to that in practice, but I suspect there is Google load limiting going on as I know that they do this. Of course this means that it can take a very long time to upload a directory of this size.
1 Like
What will happen if I roll back to the 1.5 version? Will it start to re-upload everything all over again? If not, that’s what I’m going to do until this problem is fixed.
By the way, the Linux man page, included in the package, seems to be completely out of date (as far as I can tell it’s identical to the 1.5 version). This really should be fixed immediately, even if just to replace it by a placeholder, as many of the options are not recognised.
perfeito, comprei o programa de vocês e estou amando, recomendo que façam uma tradução para mais linguagens como por exemplo portugues, a galera iria amar :))
se eu puder ajudar em algo entrem em contato
Yes ma’am, I did indeed.
Some feedback before I switch back to 1.5.7, as 3.0.11 has proven too unstable:
-
The 3.0.11 install did not run to completion on its own, instead leaving my dpkg in an unstable state, which I had to manually correct before attempting the install once again.
-
Despite the new 3.0.11 install correctly identifying that I had previously been running insync 1.5, it nevertheless proceeded to re-upload everything (or attempted to, anyway).
-
For no discernible reason, insync’s attempt to re-upload all of my files resulted in my Google Drive’s Trash filling up with 20+ GB of (apparently) duplicate data until my storage maxed out. Have you perchance changed the update mechanism so that it deletes the cloud file and then uploads a new one (as opposed to updating the existing file)?
-
Attempting to use the new OneDrive integration pulled up a browser window where I identified the MS accountt to sync and provided the correct credentials, but then nothing happened and insync seemed unaware that anything had ever transpired.
-
On several occasions, the insync app window would either fail to render at all or would become unresponsive (in every case, I gave it plenty of time to recover).
-
HiDPI is still not fully supported, requiring that insync be launched with the
env QT_AUTO_SCREEN_SCALE_FACOR=1prefix in order for the app window to be legible. -
I appreciate the simplified exception/ignore list mechanism, but it appears that text entered into the exception list textarea is not always saved when you hit “Apply”.
-
Once insync had only 2318 files left to re-upload (and with plenty of space available on Google Drive after I’d emptied the Trash a few times), it suddenly decided no additional data would ever be transferred. Despite restarting the process multiple times and giving it several hours to show any signs of progress, insync just sat there eating up well over 1GB of RAM (used mostly by the main insync process) and 60% of my CPU (used mostly by QtWebEngineProcess).
I will now be attempting to clear the 3.0.11 install/state and revert back to 1.5.7, at which point I expect I will need to re-upload everything again. … again.
I hope you find this feedback useful. I have been running insync 3.0.11.40167-bionic (amd64) on Ubuntu 19.04, BTW.
2 Likes
I’m afraid sync folders that are migrated to (or setup on) Insync 3 cannot be reused for Insync 1.5. You’ll have to resync files – cloud to local – if you’ll be re-installing 1.5.
Thanks @POC, will forward this to our Linux team. cc @Kurt_Ko
Thanks for testing Nestor, very helpful notes!
Some of these are related to known issues, but others may need more investigation from our devs. Could you send your log files to support@insynchq.com? You can link to this post for reference
I’ve sent my log files to support@insync.com.
Uploading is still ongoing, after 3 days.
EDITED August 7:
Uploading has now finished. I’ll stay with 3 for the time being and see how it goes.
1 Like
Insync-3.0.11 beta is working well so far on Linux Mint 19.2.
I would like the next updates, the Nemo icons on Linux Mint to indicate synchronization.
Thanks.
1 Like
Hi @POC,
I have a feeling it’s also the size of your Drive itself. Insync took a while to go through 300+ GB 
Perhaps, but the UI indicates that the files are being uploaded, not that they are being checked. I don’t know how Insync determines if a file has changed, but if it’s comparing checksums then it shouldn’t take that long even for 300GB.