Hi,
@mia email sent with logs and step by step instructions how to reproduce.
Please take a look and let us know the solution or if it’s fixed for next update.
Thank you.
Hi,
@mia email sent with logs and step by step instructions how to reproduce.
Please take a look and let us know the solution or if it’s fixed for next update.
Thank you.
Hi all! This is an expected behavior, and I am sharing with you the email I sent to one of our users. It includes a (hopefully) detailed explanation of this sync behavior as well as what our team plans to do moving forward:
Thank you very much for emailing about this. I have spoken to our engineers and it looks like I didn’t realize sooner that these reports on the behavior is in fact expected. If you take a look at the release notes on 3.6.0, we implemented an improvement where files that are locally removed (while Insync is offline) will be unsynced in the cloud as a way to support unwanted deletions for certain use cases. The notes can be found in-app - go to the 3 dots on the upper right > Help > click “Release Notes” on the left panel.
However, we realized further that this is not native to users who actually intend to remove such files, hence users reporting the unusual behavior. While we aim to prevent data loss as best as we can, we also want users to continuously have a seamless experience; I’ve requested an improvement to cater to both cases - those who want to delete and those who accidentally delete files while Insync is offline.
Hoping that this info helps and sheds light on what’s been going on with Insync. Would you like to be informed once the improvements have been deployed?
It may be expected behavior for you; but it clearly isn’t for all users (including myself). Can you please make it possible to switch back to the previous behavior, e.g. via a setting?
It’s in particular annoying because if I afterwards remove the online (cloud) copy too, then Insync still marks the local folder with a yellow badge rather than a green one, even though the content is fully in sync again.
Hi @timovanroermund, yes - as mentioned above, we have realized that it isn’t native to a lot of users and an improvement is lined up for this. We apologize for the trouble!
Could you let me know if the yellow check persists after restarting Insync?
Yes it persists. Only after stopping the sync and restarting the sync of that folder it gets green again. But that means that the entire folder is locally thrown away and redownloaded, which may take a long time.
@timovanroermund Hi, I can confirm that the yellow check persists and have lined this up for a fix.
Could you please expound on what do you mean that it’s being redownloaded? I deleted a local copy while Insync was offline, and when I resumed it, the file was unsynced but not redownloaded.
@mia: What I did is the the following:
I then tried fixing the yellow check mark, as follows:
The result was that all contents of the the local folder was deleted first and then, the remote content was downloaded as a new local copy. The green check mark was restored, so that part worked. However, I had expected that the client would have compared the local vs. the remote copied to conclude that both are in sync, instead of deleting the local copy first and then downloading the remote copy again. Is there another way to fix the sync status for a folder which in in sync, but erroneously is shown as ‘yellow’?
Hi @timovanroermund,
Thank you so, so much for the detailed walkthrough. It’s clear now what you meant by files being redownloaded (in line with the goal of having a green check mark on the folders).
Right now, there hasn’t been a solution to change the sync status from yellow to green without doing the steps you mentioned, although you raised a point about expecting that it would be a comparison rather than delete+download.
Let me send this to our engineers; it seems like if we fix the initial yellow checkmark issue, then stopping and re-enabling 2-way sync won’t be necessary for our users.
Hi,
@miamoran noticed a new version released today (3.7.0.50216), but there is nothing in changelog about this fix.
Is it still not fixed (improved)?
Hi @Freddy,
We are lining up the improvements in an upcoming projects cycle; v3.7.0 was part of the current cycle We’ll announce when the improvements have been deployed for this particular behavior. Thank you!
Hi @mia,
I remember I once Googled how to fully sync a folder without unsync + re-sync, and someone on the forum answered CSS button can do this.
I tried just now and found it works. Just click CSS and choose the yellow status folder, it will then turn to green status (nothing will change to folder content as local and cloud content are the same).
Hope it helps.
Thanks
Hey @BoringName
I have done this a few times myself… and I sincerely apologize for not being able to recall this nifty workaround sooner Thanks so much for helping.
@timovanroermund - could you let me know if you’ve tried this? Not unchecking but just clicking the yellow box.
Thanks, I wasn’t aware of that workaround. I just tried it, and it works.
Hereby step by step instructions for others that may have this issue as well.
The initial situation will be similar to this, with one or more folders showing a yellow badge (see red arrow):
Now click the cloud (CSS) icon on the top-right and then ‘2-way sync’ in the drop-down menu (see green arrows).
Next, you’ll see a window like this:
Now, select the ‘Select All’ button and click ‘2-way sync’:
Alternatively, you can also simply toggle (un-select and then select) the tick mark of the folder that incorrectly has the yellow badge.
And for those who (like me until a few minutes ago ) don’t know what CSS stands for, I recommend to have a look at these instructions: https://help.insynchq.com/en/articles/3010339-insync-3-ui-guide
Thanks for finding a workaround!
Anyhow, I second the view that this behavior of the software is counterintuitive and should be aligned to a proper behavior.
Before discovering this workaround, I have had the software thrash my whole system for hours due to removing and redownloading a large number of files (I’m making a huge sync across different machines now).
Thank you very much for adding your voice to a much-needed revisit to the changes we deployed. Rest assured that we will be prioritizing this in our upcoming cycle.
@timovanroermund - thank you so much for the detailed and step-by-step for our other users. You have been such a huge help here.
Happy New Year to you all. I will be updating this thread as soon as the improvements are in the works.
Hi,
@mia noticed a new version released (3.7.1.50307), but there is nothing in changelog about this fix.
Is it still not fixed (improved)?
I still have it on “Paused” since December . Removed over 10000 files from thousands of folders while being offline, don’t want to resume now since I know it won’t sync properly and don’t really want to re-sync everything (will take ages).
Could you confirm this was fixed in new version?
Hi @Freddy,
I’m glad that you asked that question here! To confirm: the fix is not yet included in said build. We will announce it on this thread to ensure proper communication
Thank you!
Hey all! We addressed this via 3.7.2: New Insync version: 3.7.2
I understand that the release notes do not include the “sync deletions” setting yet, and I have notified our engineers about this. Once you upgrade to this version, you will see a pop-up notification explaining the changes.
3.7.2 is set to sync file deletions as it did in 3.5.x builds (aka what you guys were used to), so for those who preferred the 3.6.1 to 3.7.1 setting (where it only unsyncs the files that were deleted locally while the app was offline), then you can change the behavior by going to the App Settings. Let us know how this goes!
Thank you!
Really glad it’s finally added. Keep up the good work.