I think the main problem is that there is really NO interface to the operating system GUI. The only interface is the Web browser. So if Syncthing creates empty/dummy files that “open in syncthing” for them to be on-demand downloaded, there is really no program for them to open in.
For me this is still a really important feature. I think the ignore list capability means that a good bit of the underlying code may be ready for this kind of feature. But the fundamental problem of a lack of integration with the GUI of the OS means it really can only be managed from the web interface. I would propose the following: (Of course, I have no idea how to do it…)
- A folder can be identified as a selective sync folder. It should be assured at least when identifying a folder as selective sync that there is at least one device in the cluster that does not identify it as selective. That device would always have all the files in the folder.
- Empty/Dummy files are NOT created in the selective sync folder. There’s no application to open them in. So there’s no point in them being there.
- In the web browser on the device with the selective sync folder, the user would be able to view the folder’s directory tree and “enable” sync for files or subfolders.
- When files or subfolders are selected for syncing, they are transferred from the pool and placed appropriately in the directory tree in the filesystem.
- Files can be edited and would be synced back to the pool.
- When someone is “done” with the local copy, has made any changes they desire, and ready to clean up, they would simply go back into the web UI, and “deselect” the subdirectory or files. Syncthing would then verify those files are in fact stored elsewhere in the pool, preferably on at least one device that is not selectively syncing, and then Syncthing would delete the local copy, and NOT leave the copy for the user to delete manually. This is REALLY important, because it would be too easy for a user to unsync files, and then delete other files they’re still syncing by mistake… And then, of course, they’re gone from the whole pool.
- There would have to be a substantial amount of testing particularly if individual file syncing was permitted… I.e. if new files are created, those are also presumably selectively synced (not ignored). An alternative is to say selective sync only works on subfolders. And it’s all or nothing (the whole subfolder or not).
Additionally I would advocate this selective sync, sync list be SEPARATE from the existing ignore list. Even if it’s possible the ignore list capability is the underlying capability used to implement, the selective sync list should be completely managed from the WebUI, and the ignore list sort-of combined with the selective sync list which is perhaps hidden (Don’t need to show the user how the sausage is made.)
The benefit of this kind of solution is it doesn’t require any change to the architecture. There is no need to create “helper” applications for each OS. It’s all managed through the WebUI.
Anyway, just my thoughts after using Resilio for years and switching to Syncthing for some of the reasons mentioned here.
Let me know if you guys think this makes sense…