So I sync some local files to GD. Then, offline/with insync closed, I make various changes and delete a few files. When I start insync again, I expect all changes and deletions to be sent to GD — but instead, the deleted files remain in GD. In the insync main window, the folders have a yellow checkmark, and the deleted files show up with a “1-way sync only available for top level photos” notice.
I have exactly the same issue.
It works fine if you delete the files while “online”, but if you delete them “offline” (or just while on “paused syncing”) and resume syncing later they are not deleted in GD.
Interested in solution.
Hi @Freddy and @mayhplumb!
Could you please send your logs.db and out.txt files to support@insynchq.com with the link to this post? You may refer to this guide on how to find your logs.
Thank you very much!
1 Like
Hi,
I have exactly the same issue. When I delete some files locally during ‘paused’ state, the insync will unsync that folder/file and turn into partial sync for its parent folder after resumed, making the files remain on Google Drive.
Hope this can be fixed soon.
Thanks a lot.
2 Likes
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? 
1 Like
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 first deleted a local file while Insync was offline, which resulted in the yellow check mark and that the remote file remained in place (i.e., the new but unexpected behavior).
- I then removed the remote file as well (which Insync was running), such that the content of the remote and local folders were the same again; however, the yellow check mark remained (as you confirmed – so good to hear that this will get fixed).
I then tried fixing the yellow check mark, as follows:
- I stopped the 2-way syncing for the folder which had the yellow check mark
- I then enabled 2-way sync again for the same folder.
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
1 Like
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
3 Likes
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.
1 Like
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?