Here’s a proposal I sent in through the support channel as a way for our Insync developer friends to add symlink functionality to 3.x. I’ve also posted it here for your reading pleasure, and to solicit “likes” to help indicate demand.
If you need/want this feature, please click the little heart to like this post!!!
Neither Google Drive nor Microsoft OneDrive seem to support true symlinks, so this proposal allows local (Linux side) use of symlinks, with Insync storing their metadata as a normal file in Google Drive or OneDrive.
For the rest of this post, I’ll use “$cloudDrive” to indicate either Google Drive or Microsoft OneDrive.
Here’s how it works:
On the local Linux file system you have a symlink, such as /home/user/images which points to a target of /var/lib/images. For this proposed solution, it doesn’t matter if the target is a file or a directory.
Note that we only expect Insync to sync the symlink itself as a special file, and we do not expect (or want) Insync to sync the target of the symlink.
When Insync encounters a symlink on the local system, it syncs to $cloudDrive a file with the same name as the symlink, but with metadata that describes the symlink. By using the same name for the symlink metafile in $cloudDrive as the symlink on the local system, we implicitly avoid naming conflicts.
So what gets put into the symlink metafile on $cloudDrive? Here’s an example:
# This is a symlink metafile created by Insync to track this symlink on your local filesystem
"symlink":
{
"link": "/home/user/images",
"target": "/var/lib/images"
}
When Insync is syncing from the cloud to the local file system, it simply re-creates the local symlink based on the metadata.
Pros
- Works with Google Drive, OneDrive, and any other $cloudDrive that supports text files
- Very simple conceptual model
- Is self-documenting
- In the case of a restore from $cloudDrive where Insync is not available, these symlink metafiles can be fed into a pretty simple shell script to re-create the local links.
- Naming the special file type in the metadata “symlink” makes it extensible, allowing for potential support of other special file types in the future.
Cons
