Bruce Howells
Cadet
- Joined
- Jan 13, 2017
- Messages
- 5
So, I have a repository of rear (relax and recover) images that are symlink-heavy, and Cloud Sync (ie, rclone)'ed it out to a couple remotes. All seemed fine, until I needed to pull the files back.
It looks like the default rclone settings generated for a Cloud Sync task include neither -l (which would sync a copy of the referred file, not preserve the symlink) or -L (which preserves the symlink by saving it on upload and recreating it on download.) As a result, symlinks are silently broken.
This is likely an unpleasant surprise to those expecting the lightly-documented Cloud Sync feature to, well, sync.
It probably makes sense to surface this in the UI somewhere, but in the meantime, forcing -L gives me the behavior I need... and might actually be the right thing to file a bug report suggesting.
Any guidance on how to apply a local change so my generated rclone.conf includes -L?
And should I suggest that -L (preserve symlinks, recreate them on restore) be the default behavior (vs. losing symlinks on copy)?
It looks like the default rclone settings generated for a Cloud Sync task include neither -l (which would sync a copy of the referred file, not preserve the symlink) or -L (which preserves the symlink by saving it on upload and recreating it on download.) As a result, symlinks are silently broken.
This is likely an unpleasant surprise to those expecting the lightly-documented Cloud Sync feature to, well, sync.
It probably makes sense to surface this in the UI somewhere, but in the meantime, forcing -L gives me the behavior I need... and might actually be the right thing to file a bug report suggesting.
Any guidance on how to apply a local change so my generated rclone.conf includes -L?
And should I suggest that -L (preserve symlinks, recreate them on restore) be the default behavior (vs. losing symlinks on copy)?