This is a typical error state of InSync about a month ago. In the db the parent ID of the referred file/folder points to itself, so it’s an endless loop. The most important effect in this situation, that syncing halts. The only solution: to write 1 in the parent ID field in the live_fs_files table in the db. It will not cause problem, because, as I experienced, the problem is always on a directory which doesn’t reside in the filesystem, it was always a subfolder of a symlinked folder or a junction point from another fs (which is not always available).
I’m using junction points regularly, but a month ago was the first time, when I created these from outside of the synced folder (and the fs belonging to it). Why InSync trying sync nonregular files/folders when it’s obviously impossible (and why doesn’t it cause any problems when target is on the same fs)?
Currently 1.4.7.37098 on Windows 10.0.17134.48, but originally I run into this problem with InSync 1.3, then I install the update.
Hello @blr,
What is the file system, hardware (& OS) of the target/symlinked folder? It appears that the target fs is incompatible with Insync – Insync relies on every file having a unique FileIndex/inode.
Thanks
The target is Google Drive File Stream. But why InSync try to sync that?
@blr Insync That’s the intended behaviour, Insync attempts to sync the contents present inside the targets of junctions/symlinks present inside the Insync folder. Here since the target is a virtual file system which may not be fully compliant with the FS standards, Insync could be encountering issues while syncing the target. We will look into whether we can/should avoid syncing such targets altogether.
Thanks
I don’t think that anybody want to sync linked folders, especially not symlinked folders.
I’ve never met before any file management software which automatically (without option to disable) follows symbolic links. Most of the cases this is an opt in possibility.
On the contrary, a major MAJOR use case for Insync is precisely that it can sync through symlinks. This is how they can support syncing external folders.
A major drawback in the official Google Drive client is that it doesn’t sync through symlinks. Many other official cloud sync clients (e.g. Dropbox) sync through symlinks.
Insync supports external folders through junction points, not symlinks.
It’s symlinks, not junction points. Try dir and see the type. It’s <SYMLINKD>.
Regardless, using symlinks to support syncing external folders is a very standard behavior among various sync clients.
Last time when I try to add folder to sync, it was junction point. Now it’s symlink. I don’t know when it was changed.
I think, I have to find another sync solution.
Did you ever think about what will happen when the linked folder points to another synced folder in another account? All files will be exists on both account. I don’t even want to think about link a folder more than one time… Is that the intended behaviour?
@blr If the target folder is already being sync’d by that Insync instance, Insync would ignore it and won’t upload/sync it under the new path.
Ignores only synced by same account, not by same instance. That’s my problem.