We’ll need a path forward.
I made a backup copy of the original, then copied everything to the new “small i” folder.
Restarted the app and it all went back to normal.
Using POP_OS latest, auto update.
I have it installed on a Fedora VM but I haven’t opened it yet.
Also installed on macOS and the update went smooth.
I made a backup copy of the original, then copied everything to the new “small i” folder.
Restarted the app and it all went back to normal.
Thank, works fine here as well. (Ubuntu 20.04.4 LTS)
The new one is the small “i” insync. Yes, they both had the same timestamps from the update - closed one, opened the other.
Unless you reconnected it with your sync folder after the update (i.e. - started from scratch again) you should find the the data and live folders in the new insync folder are empty and you move your .db files from the old Insync folders (data and live) there. Also remember the settings.db file as I mentioned in the previous post.
AND - make sure you’ve quit insync before you do any of this!
If you already have files in the new insync data and live folders I’m not sure what to tell you. You could rename them and try copying in the old ones and see if that works.
Only thing I’m worried about is that they will push out another update to “fix” this and that will break this “fix”.
Holy … k
Hope they don’t and check this thread before
I can confirm that this approach appears to have worked for me. At first I tried renaming the ~/.config/insync folder out of the way, and then created a symlink to the ~/config/Insync folder, but that crashed Insync. So I used your approach and that worked.
Thanks.
I also solved just deleting ~/.config/insync and renaming ~/.config/Insync to ~/.config/insync .
Can confirm this is the simplest and correct solution.
Please be very careful with symlinking different directories together etc, you may make life harder for yourself in future.
The developers really need some better automated testing to catch nonsense like this… We’re on these forums and can see what’s happening but the vast majority of users have just experienced data loss and are probably unlikely to continue to use InSync.
I didn’t notice - is there an official way to submit a bug or best to just post in the forums?
This forum is also the works as the public bug tracker. Bug reports are tagged appropriately. Normally they’re very responsive, but COVID has hurt the rhythm a bit.
Hello everyone. Mia here, speaking on behalf of the Insync team.
We truly and sincerely apologize for the serious bug that 3.7.4 introduced for Linux users. We understand that our words simply won’t take back what has happened to those who have lost their previous Insync configuration and needed to start over, as well as for those of you who needed to find a solution as quickly as possible.
Our engineers have been alerted on the urgency of this situation. They are working on rolling back 3.7.4 on Linux both in our webpage and the repositories so that it will not be further accessed by our Linux community while we address the issue.
The fix will be deployed in v3.7.5 – rest assured that we will take your workaround into account to ensure that the next version goes smoothly for everyone, including the affected users who have renamed their Insync config folder. We are also implementing stricter measures in the testing phase to avoid anything like this again moving forward.
Please don’t hesitate to comment here or reach out via email if you have any questions or concerns.
Thanks for the update! Indeed, after reconfiguring Insync I now have .config/Insync and .config/insync
Can I safely delete the old capital-I Insync folder? Or will 7.3.5 revert to the previous name?
Cheers: Chris
I ran the update this morning, about 9 hours ago, and that’s when I found this thread. Disappointed that there’s been no official acknowledgement of the issue as of yet (although perhaps I just missed it).
I didn’t run the Insync setup after the update so it appears that I still have my ~/.config/Insync folder intact, but I would like to hear from the company before proceeding with any work-around. If they’re going to issue a fix using Insync rather than insync, I’ll wait for that.
This very thread has the official response via miamoran, as of 5 hours ago. The post itself is here.
Thanks for pointing that out. I submitted my comment about 4 hours before the official response, but because I had never used the forum before, my post was put on moderation.
No worries, we’re all starting from the same point. Welcome to the community!
Hi Mia,
Can you confirm this bug is affecting only Linux users? I’m having another issue related to the upgrade but didn’t want to post it if it’s tied somehow to this thread’s issue.
Let me know if it’s unrelated and I’ll submit a proper bug with logs, etc. - but basically I’m getting a message to upgrade and restart, but nothing seems to happen when I click on the link (there is no upgrade or restart (have quit Insync and restarted/rebooted and old version number is still present and I’m prompted again to Update and restart. I’ve made sure no syncing is in progress before clicking on the Update and restart app link. I’ve tried this 4 or 5 times with the same result.
HI @brandtryan,
Yes, this particular issue on lost configuration/settings is only Linux-specific.
Could you please send the following to support@insynchq.com with the link to this post:
- logs.db
- out.txt
- “data” folder
- “live” folder
Those files can be located by following this guide. Thank you!
Hi @Christian_Frank,
This is the simplest workaround that has been effective for users: Lost settings & a couple of crashes after 3.7.4 upgrade
Hello all! For those wondering what would happen to your current settings (if you started over) once 3.7.5 is rolled out, I addressed it here. Thank you!