rclone lets folders with symbolic links be synchronized with cloud providers that do not support symbolic links by translating them to special text files containing the destination the link points to while on flight to the cloud, and then back to symbolic links while on flight from the cloud. The behavior is activated with the
--links option. These special files have names formed from the name of the link with the
.rclonelink extension and contain just the link destination.
rclone is not the only program using this kind of approach. As an example, there is a special
fuse overlay filesystem called
nlinkfs that performs exactly the same operation.
The problem here is that every application using the approach has its own opinion on how the files representing the symbolic links should be named and internally arranged and all of them are incompatible. It would be nice if
rclone could provide a few different styles (e.g., via a
--links-style option). I am thinking about:
--link-style=rclone (default), i.e. the current behavior
--link-style=nlinkfs, i.e. the
nlinkfs style: links have the
.LNK extension and prepend a special signature to the link destination.
- possibly others.
This would favor interoperability. Usage case: you started using some cloud provider with a dedicated sync client not supporting symlinks. Because you needed them, you used
nlinkfs as a translation layer. Then you learn about
rclone and you want to use it, but
rclone cannot deal with the
.LNK files that are already in the cloud.
I've not heard of nlinkfs before. Are there other programs like that?
--links-style would be implemented in the local backend. It would be relatively easy to do, but I'm unsure of whether it would be of general interest enough?
As another example I can think of
cygwin that simulates POSIX-compliant symbolic links in the Microsoft Windows file system by creating (special) Windows shortcuts (.lnk files) with additional information used (by Cygwin) at the time of symlink resolution. Cygwin "symlinks" are quite interesting because they can be "interpreted" as posix symbolic links by cygwin and at the same time they are valid windows shortcuts. So,
--link-style=cygwin could be another interesting option, possibly slightly more complicated to implement.
To me the interest in this option is to facilitate migration to
rclone. Sample case: Mr. A starts working with OneDrive using the excellent
onedrive client for linux by abraunegg. Because that client has no trick to deal with symlinks, nlinkfs is used as a translation layer. Namely, Mr. A has "Folder-nolinks" mounted to "Folder" where he normally works. Then he synchronizes "Folder-nolinks" to OneDrive. At some point Mr. A decides he would like to use
rclone instead, because it makes it easier to move things around to other clouds (and now it also supports
bisync). The remote is full of
.LNK files that
rclone cannot currently understand, though.
Sorry to post again, without any actual news about the problem.
Being new to
rclone and its forum and bug tracker, it is unclear to me if I should I open a feature request on the bug tracker, or if it is enough to have it reported here. I suspect this is the case, as a courtesy to other users who might look for the feature and will avoid double posting if they find the wishlist on the tracker.
Thanks in advance for hinting at the correct action.
Making an issue about this would be the correct way of keeping this for posterity.
If you want to summarize the discussion here (and put a link) into the issue that would be great.
As for when it might get done? That depends on user interest which we can collect on the issue tracker.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.