lib/scanner: Add option to follow symlinks#3387
lib/scanner: Add option to follow symlinks#3387calmh wants to merge 1 commit intosyncthing:masterfrom calmh:fix-1776
Conversation
This adds the ability to follow some symlinks when scanning. Symlinks to files are not supported. We could support this on the scanner side, it's not super difficult, but it's a little bit more involved on the puller side. At the moment I think that's less important so I'm leaving it for the future.
|
The ❌ for Windows in the test results tells me that there may be some adjustment needed there... |
| goto ok | ||
| } | ||
| } | ||
| continue nextSymlink |
There was a problem hiding this comment.
Don't understand this whole magic.
I think the FollowSymlinks should be existing symlinks that are relative to the folder root.
There was a problem hiding this comment.
It is. But we need to call Walk() on it, which we can't cleanly do inside the walkFn
|
OK I might as well implement it for files as well if it's worth doing at all. |
|
Other notable restrictions would be that
|
|
In principle, this is going in the right direction, but frankly, it's a disaster from a users POV. With your approach I might end up with say 100 symlinks in the config. Not funny. From the user POV, the better logic would be a boolean per folder: if true, follow them, or not otherwise. Versioning is not compatible of course, and it might even be a good idea to handle this folder read only (from syncthing perspective). |
|
I'm not a dev but I do understand the purposes of symbolic links are useful but can be complex. I just want to say that a good example of their usage in backup software is in a Mac OSX app called GoodSync. This is the app I use in the meantime of Syncthing having a follow symbolic link feature. For instance, within the app, when you've set a "job" (aka the syncing of two folders), either folder can have symbolic links within it, which you can in the job settings indicate to be ignored, copied as-is, or drilled into. When you chose to drill into symbolic links, when syncing occurs, it will sync the original files, as if they were in the folder instead of the symbolic links. This is immensely useful for certain job applications. One situation I find myself needing symbolic links for is in the syncing of my ebooks collection to my android tablet for reading. The collection is large, so I cannot sync them all. Likewise, it is well organized into folders and subfolders according to genres, categories, purposes, etc. Sometimes, I want to sync just a few books from here and a few from there, so I use symbolic links to create a "To Sync" folder at the root of the drive, which reflects a unique folder structure which makes browsing on the tablet much easier than the complex structure on the desktop. The reason using an .stignore file within Syncthing is not functional, is because 1) I need the folder structure synced to the tablet to be different than the desktop (for ease of use), and 2) Sometimes I add new ebooks to folders, and I can't always go edit the ignore file to reflect ignoring that new ebook. Using GoodSync to sync my ebooks (among other things) has been the only solution to my needs so far. However the shortcoming of it is that I must be on my home network to initiate the sync. Syncthing is great because I can be anywhere, like at a friends house or the library, and sync a file I need. If you're looking for any inspiration or clarification to how symbolic link syncing would work, try taking a look at GoodSync and see how they make it work. If you could replicate how they do it within Syncthing, you'd have a vastly superior product. Sorry I can't do more to help with the actual development, but I thought at least portraying these thoughts might help someone here along. |
|
@frispete a per folder option sounds like a natural thing to do |
st-review
added
the
frozen-due-to-age
6 participants
This is a tech preview, not done yet, not for merging. Specifically there is no UI. For discussion to see if I'm along the right path.
Purpose
This adds the ability to follow some symlinks when scanning.
The principle is that the symlinks to follow must be explicitly named in the config - those, and only those, are followed.
Only symlinks to directories are supported - not symlinks to files. We could support that on the scanner side, it's not super difficult, but it's a little bit more involved on the puller side as we don't want to replace the symlink when pulling and we need to create the temp files on the other side of the symlink etc. At the moment I think that's less important so I'm leaving it for the future.
Testing
Unit tested on the scanner side... Puller side should be fine, it should just go through the symlink. No idea how well any of this works on Windows...