Surely this is only a workaround, and you need to fix the code? And if I workaround it, how will you ever know if you’ve properly fixed the code?
Hi @xpusostomos,
Currently, it is a potential workaround and we will need to fetch user logs before and after resyncing to investigate the issue further. Thank you!
I already sent you all the logs and stuff. Never heard anything about it afterwards. It seems to me that these files, being linked from someone else’s google drive account are readonly, and insync isn’t smart enough to realise that and ignore them.
Bump… the cause of this bug is clear and obvious… trying to sync files that are readonly and linked from someone else’s account. No excuse for not fixing this for like 9 months.
Hi @xpusostomos,
After investigating this again, it seems like we cannot trace any indication in the logs how the local-to-cloud sync of the said files were triggered. Is it possible at all that another software may have triggered it?
When you suggested that Insync should not update a shared directory either locally or in the cloud (as a non-owner), this would only applicable when sharing with Can view permissions. In the case of Can organize, add, & edit, Insync should be able to update the shared directory.
I don’t know what that means “another software may have triggered”… how would another software trigger it? In my imagination, Insync would be triggered by timestamps or something, and the Date Modified timestamps are years old. And there is no difference in the timestamp of the problematic files with the hundreds of files in the same directory. They may well be map files that I accessed in my mapping software… in fact they would certainly be, since the particular files in question are maps of areas I’m interested in, but… they weren’t modified, they are read only maps.
Yes sure, writable shared directories should be updatable… but this directory is not updatable. If I try in google drive to upload to that folder it says “You do not permission to upload to this folder”. You can try it yourself, this is a publicly shared google drive cache of maps: https://drive.google.com/drive/folders/1XSAHAqSXN472R7GWXKxm1U9VUoWsR5vg?usp=sharing
I don’t know what that means “another software may have triggered”… how would another software trigger it
What we mean by this is that sometimes, some other software could have performed the modifications of the files (possibly just the metadata) which may have prompted Insync to attempt to sync them.
Our engineers have been made aware of the issue wherein Insync tries to sync local changes to a shared file (w/ read permissions) to the cloud – it shouldn’t happen and we will be working on improving it. 
If there is some specific metadata you want me to check, I can check it. The modification times are ancient. The access times are also ancient (although I believe on Windows 10, updates to access times are disabled by default anyway). Not sure what other metadata there could be. Since Google seemingly only keeps the modification time as metadata, it wouldn’t seem to make much sense to check anything else.
1 Like
I’ll consult with our engineers to see if a specific metadata can or needs to be checked on your end!
Your development team doesn’t seem to have the necessary skills to resolve problems. How can it be, that I have failed sync messages for nearly a year now… I can press “Retry” a zillion times, and it doesn’t resolve it. The software has no robustness against recovering from errors. Why should anyone use this software? You’re not taking problems seriously, you’re not getting them resolved.
I had to completely reinstall Windows 11 to get it to work, and resync Google drive from scratch. And STILL insync is giving me the BOGUS error that it can’t modify files that are not owned by my Google drive.
Oh how much longer must I suffer. This is nearly 18 months old now.
GET YOUR ACT TOGETHER.
Hi @xpusostomos,
Since it’s a clean re-install/re-sync, please do send me the latest logs.db and out.txt (to support@insynchq.com) so I can follow it up with our engineers.
Only 2 years now living with this bug and see the little red incync icon failure symbol on all my machines.
Maybe after 5 years your engineers might get off their asses and fix this maybe?
Hi @xpusostomos,
We understand your sentiments regarding this long-standing issue regarding the permission errors.
Our engineers already have a proposed solution, while we do not have this included in our current projects cycle yet (due to more pressing issues and bugs), I have lined this up to be revisited as soon as we can.
Thank you.
Why must you continue to push out new features when you can’t get your core product working?
Hello @xpusostomos,
Releasing features, improvements, and updates depend on user feedback from support channels as well as careful research done by our team through regular surveys we send out on top of reported bugs that have its process of prioritization (urgency, number of users, etc).
Each user may have a unique workflow, and thus we have to assess how it fits in our pipeline and how it would affect the rest of the community should XYZ be included in the product. As mentioned in my last response, the proposed solution has been discussed and we will be reassessing where and how it can fit in our succeeding projects cycle.
Thank you.
Looks like this bug is actually getting worse over time, not better. Now I’m getting an error “There is a file conflict for EON-NSL-ACT-Canberra-15.map in which a local edit happened at the same time as cloud delete.” This is a file I haven’t even accessed in months, whose timestamp is 4 years old, and there is no “cloud delete” the file is still there safe and sound at drive.google.com It’s too scarey to keep using this software that thinks your files are deleted and then is going to do who knows what. I’ve had enough of this junk, I’m out.
Hi @xpusostomos,
We apologize for the persistent troubles you’ve been facing on Insync! I can’t imagine the hassle of having to worry about your file’s safety while the app is running 
If you would like for us to check out this conflict in particular, feel free to send your logs.db and out.txt files to me at support@insynchq.com with the link to this post.