Can't resolve 'paused because it went missing'

Bugs and issues Linux
#1

Running insync-headless on Debian Linux.

I have an error status and a required action that says:
“Syncing for X is paused because it went missing”

In this case, X actually does not exist, but X is NOT in the directory tree that insync manages. I assume that there’s a dangling symlink in the insync tree that points to X. I found one such symlink and fixed it, but the error has not gone away. I’ve done an exhaustive search, and I don’t think there are any more bad symlinks. How can I clear the error, or find the location of the symlink (if that’s what it is) that’s generating the error?

I tried ‘retry_errors’ and restarting insync itself.

#2

@Bill_Kuhns1: You could try find /path/to/Insync/folder -type l -ls to find all symlinks under the Insync folder.

#3

I did that. There are hundreds of symlinks, so I actually did

find /path/to/Insync/folder -type l -ls | grep unique-part-of-X-with-no-special-regexp-chars

There used to be a symlink that pointed to X, but I fixed it before my first post. The error doesn’t go away, though.

#4

@Bill_Kuhns1: I see. Please try unchecking the symlink in the selective sync interface. If that didn’t work instead try removing the folder that contains the symlink out of the Insync folder, wait for changes to sync, then put it back.

#5

I’m running insync-headless, so there’s no check. Also no symlinks at the top level of the insync directory, so I’m not clear exactly what you’re asking me to do.

I don’t have any idea where the problem is, since the message doesn’t contain the path or name of the file causing the problem. ‘X’ appears to be the destination that a symlink points to, not the filename of the symlink itself. ‘X’ is outside of the insync directory tree.

The directory where the original bad symlink is is the parent of a large subtree that would take at least a day to sync and resync, and moving it would break a lot of things and prevent work during that period.

I recreated ‘X’ as an empty file and temporarily deleted the symlink that used to point to X. That seems to have fixed the problem.

Suggestion: Provide more actionable information on errors - get_actions_required was pretty useless in this case. Also, the internal logic that flagged the error should have cleared it when the symlink was fixed.

#6

@Bill_Kuhns1: Yeah, the headless client still needs a lot of improvements in that regard. The GUI client has choices to resolve that issue but they’re not implemented in the headless client yet. I’ll add that to the list.

#7

Thanks. In general, errors, required actions, and error clearing all seem to be a bit obscure. I have a new one that’s a ‘file not found’ for a Google sheet. It doesn’t show any action required. The file is truly missing from Google - how do I clear the error? I don’t want to have an error status forever.

#8

@Bill_Kuhns1: Apologies for the trouble. If you have an idea where the file was located before try unselecting it or its parent in the selective sync interface to check if that resolves the issue. If it didn’t work please send us your logs for investigation: How to find the log files.

If you unselect the parent folder Insync will delete it from your computer, just fyi.

#9

Been on the road - sorry for the delay. I still see the error. Can’t unselect the parent since I don’t know what it was. I also am running headless so there’s no ‘selective sync interface’ to be found.

Where do I send the logs?

#10

@Bill_Kuhns1: Please send it to support@insynchq.com

#11

I have a raft of similar errors. One in particular is for a folder which contains a hidden folder which contains a broken symlink (to a file in a deleted folder that was adjacent to the hidden folder).

mui mui/node_modules/.bin/loose-envify -> ../loose-envify/cli.js

The folder .bin is what Insync is complaining about.

I seem to be able to reproduce this situation by making
adjacentFolder/ adjacentFolder/testfile folderToDelete/ folderToDelete/testfile -> ../adjacentFolder/testfile

Then deleting adjacentFolder locally, then deleting folderToDelete in Google Drive (where it shows up as empty).

I have several other “Could not delete” errors as well (where the folder in question, or even its parent or grandparent are not on Google Drive), where it also appears that broken symlinks to other paths within my drive are to blame. Probably such symlinks should just be deleted, but I guess you don’t want to make that decision for me. A more helpful error message at least would be nice, though.

My solution at the moment is to use the “Open location” link as a shortcut, open a terminal there, and do
find . -type l -exec sh -c 'for x; do [ -e "$x" ] || rm "$x"; done' _ {} +
(from here) to recursively delete broken symlinks under that directory. Insync is then able to clean them up.

However, there was one case of an alternate situation–an unbroken symlink to another locations within my drive. In fact, it was a symlink to a target outside (~/.pythonpath), which itself was a symlink back to inside. I went ahead and deleted the first link, and Insync resolved it.

The final Action Required was neither of these cases–a normal drwxrwxr-x folder, with a normal -rw-rw-r-- file in it. Running my symlink clearing one-liner on this folder dos not allow Insync to resolve it on retry.

#12

@tsbertalan: Thanks for the info. Please send your logs to support@insynchq.com so we can check the root cause of your issue: How to find the log files.