If I delete a file in google drive, it isn't deleted locally; it's uploaded again.
I see that there are some post speeking about this but I didn't find a solution.
Can you help me, please?
deleting not possible(6 posts) (3 voices)
Hi,Posted 2 years ago #
There can be a few causes of this. The most common are:
1. You don't have write access to delete the file locally. Try running Syncdocs "As Administrator".
2. The file is shared on Google. You have deleted it, but someone else has modified and it has automatically been re-shared with you. Check if it is still there, or in the Trash folder on Google.
3. A less common case is that the file is locked or in-use locally (say a Word document being edited). Syncdocs will delete it when it is no longer in use.Posted 2 years ago #
I really wanted to stick with Syncdocs but I think it's time to give up. Phil, you've been kind and tried, but this delete thing has been a problem for years, and I'm exhausted fighting it. It's not Admin permissions, and it's not Google file sharing. You might want to look into Terminal Services concerns. For sure you should put in the ability to turn on some really rich, verbose diagnostics to the log file whenever a file is deleted, added, or updated so that the sync logic can be examined in detail and you don't have to keep pasting the above response whenever it doesn't work for someone.
The bottom line is that deleted files reappear. Like always. And no logs sent to you have found the problem. Diagnostics are insufficient to explain the issue. Thanks for trying. The price was right but this issue is too much to continue to tolerate.
Paul, thank you for the detailed feedback - do you only see the problem on Terminal Services environments?
I'll give you the info, but if you don't have detailed logging to turn on and use to exactly nail why this is happening, I don't want to go around in circles guessing anymore.
I run (ran) Syncdocs on a Windows 2003 Server under the admin account, which I also accessed via RDP under the same admin account. Syncdocs may be running twice under those conditions, not sure. A common mistake in my experience with software in a Windows terminal services situation is to not plan for such a condition.
I also ran Syncdocs at work under a normal account with local administrator rights.
Whenever I delete a file on my work laptop, my home Windows server via RDP, or my home Windows server via direct terminal access, within minutes the file will reappear.
The only reliable way that I have found to deal with the problem is to shut down Syncdocs everywhere, access Google Drive directly, and delete or reorganize files there. Then I can turn back on Syncdocs (a complete exit/restart) on both machines.
This sort of process is too cumbersome to continue.
Let me add one more bit of info. If I delete a file in Google Drive *without turning off all instances of Syncdocs* then it also reappears at each computer running Syndocs. The only workaround is to disable all instances of Syncdocs, then delete in Google Drive, then reactivate all Syncdocs. So the entire process takes time because I have to deactivate at work, go home, deactivate at home, then do the deletes, then turn things back on. It's been a while since I fought with this, but I think it is possible that I also have to match the deletes at each location before turning Syndocs back on. Regardless the process of getting encrypted files synched is error prone and cumbersome, and also poor in terms of bandwidth consumption due to all of the back and forth to get things right.
You must log in to post.