不按流量计费，免费空间只有1G，流量花不了多少。
但是这个同步我用下来感觉还不行，经常出错，不知道是插件开发的问题还是seafile本身的问题
另外文件在seafile上是明文存储的，暂时还不支持加密
3 个赞
我用了，也是频繁出错。看来根本没有办法日用。
应该是由于这个：
大于40kb的文件的同步都会出问题。
1 个赞
seafile插件作者回复了，说最近会修这个Bug
1 个赞
我是 remotely save 作者。
这要看思源笔记用什么方式同步的。特别地，同步到 s3 上面的文件能直接读取吗？在网页直接上传文件，本地能正确同步下来吗？s3 里没有其他不是用户知道的文件吗？
我不知道思源怎么解决的（没用过只听说过）。
remotely save 支持上述场景，基本上把 s3 当网盘用。这里的代价就是不能假定网盘内容的变化，，从而每次同步都要扫描一次 s3 文件列表，然后比较发生了变化的文件，然后增量上传下载。扫文件列表这里，是最大且很难绕过的限制，实际上时间都浪费在这里了。
假如放弃上述假设（s3 不是网盘了，而是数据库了），那么就有别的方案可以快速同步了，代价就是出问题的话，s3 里的文件是不可读的。
5 个赞
谢谢。非常困难，基本上要加辅助文件。要支持手机端则更困难了。
2 个赞
思源存储在S3上的文件是不能直接阅读的的，应该就是把S3当成数据库了。
思源的同步确实不如remotely save无感，每次打开和关闭都要等同步。而且原则上来说不允许两端同时同步。
思源开源了同步的模块感觉应该会比较复杂吧？思源在github上开源了同步的代码 siyuan-note/dejavu: Data repo for SiYuan (github.com)，可惜我是编程苦手，几乎看不懂。
思源的.sy格式是一个单行的json，里面的元数据非常多，思源的同步实现看起来很依赖json格式读取速度快和.sy文件里面保存的大量元数据。图里面这一段反映到格式化之后的json数据中就是这样的一堆。
2 个赞
此外开源部分是 agpl 协议，remotely save 是不能参考的。
总而言之思路不同，没办法。
3 个赞
首先，感谢 @fyears 大佬提供这么好的插件！ 
我突然有个不成熟的想法，不知是否可行或欠考虑的地方，请教大佬帮忙分析分析！
由于remotely save插件是能感受到本地文件的实时变化的，那么有没有可能给每个客户端设置一个文件变化清单，比如有A，B，C三个客户端，那就生成A_list.log，B_list.log，C_list.log，log里记录这客户端文件的变化情况。
那么在同步时，只需要先同步这几个log文件，然后通过log文件内容的对比，即可知道每个客户端的修改情况，这样的话，就不用每次都读取文件列表然后再对比文件是否改变了。
当然，为了保证数据的准确性，也可以配合闲时进行文件全扫描的方式。
注：由于没研究过同步方案，也没读过remotely save源码，这个方法可能还有诸多问题，不足的地方还请大佬指正！由于对remotely save不熟，如果对remotely save有误解的地方还请海涵！
假如你直接去 s3 网站手动上传或者更改了文件的话，怎么办？
感谢大佬回复！
确实是，这种情况就没办法了，不知道闲时扫描再补救是否可行。
如果不行的话，我觉得可以把这种情况告知用户，不能手动直接更改服务器，如果必须手动更改的，必须新建个同名文件，比如修改了a.md，就新建个空文件a.rslog或者把修改文件加入一个手动修改清单文件中，比如，user_rs_log.md，这样的话就可以通过扫描xxx.rslog或user_rs_log.md来实现同步用户修改的目的，然后同步完成删除临时log文件即可。
或者简单点，告知用户手动修改文件后，必须手动全量同步一次等，如果修改文件较多的话。如果修改的文件少，也可以提供手动直接同步个别文件的菜单等。
我觉得，如果速度还可以的话，可以提供一种这种选项，并告知用户情况。应该利大于弊吧，毕竟直接修改服务器的场景不多。
严格来说，obsidian也不能通过外部软件修改，外部修改也是有问题的，比如外链的维护等可能就失效了。
我觉得吧，rs就像ob内置的同步一样方便，而且简单易用，如果速度和性能尚可，我觉做一些取舍得还是值得的。
1 个赞
有没有可能在设置中加入一个选项，开启后就按照假定用户不会手动在s3网站上上传或者更改？这是一个默认关闭的选项，让那些能遵守的用户使用。
的确会出现这种情况，不过主要原因还是S3的文件结构方面以文件展开，导致无法再bucket这一层面或者父文件夹这一层面给出修改时间这一参数。举例来说，obVault->folder->file中，修改file在以下协议中
| 协议 | 整个库的更新时间以何修改时间为准 |
|---|---|
| S3 | folder |
| webdav | folder |
| Onedrive | file |
| dropbox | file |
| googledrive | folder |
可见S3无法直接查询递归子目录下的文件更新时间，就需要额外的数据库来判断，但是像Onedrive和dropbox则无需。如果想要结合这样网盘优秀的第三方更改，就意味着需要多一些代码量，但是不知道这样的代码量和较少的人数需求能否让作者有意愿开发（个人支持放在pro）功能中。
3 个赞
哈哈，所有能被用户乱改的，都会有用户乱改。不行的。反而是像思源那样用特定格式避免用户手动修改才是可行的。
4 个赞
【注意】下面这个帖子是很久以前的，现在还算稳定，反响不错，这个帖子不具有参考价值了。
思源同步也没想象的那么好，还是自己同步的好
2 个赞
rs的方案是可以多设备可以同时同步，自行解决冲突。
若限制同时同步，可以把同步后的扫描结果对象化保存在云端。下次同步，直接下载云端这个对象，和本地比较，就应该快好多。
或者换个思路，2000多个文件，会变动的应该很少，规划一下目录结构，不常变动的，就使用本地比对同步工具，经常变动的才用rs，控制rs的规模，换取时间上的丝滑。
1 个赞
假如你直接去 s3 网站手动上传或者更改了文件的话，怎么办？
相关提案 #30
针对这个问题，我后来想了想，应该把功能分为同步和备份两种方式。
同步具有及时性，主要目的是实现多客户端数据的一致性，在这个过程中的云端数据不一定非要是可视的，可以用自己的格式控制同步格式，比如思源就是通过快照。
而备份有一定的延迟，数据格式是和客户端保持一致，方便恢复。
如果有了以上前提，那么就能杜绝用户去s3更改文件的可能。不过我认为最简单的办法是让用户感知到不可更改性即可，如果非改不可，那自然后果自然自负，比如简单的改下扩展名，比如xxx.md.rs，用户是无法打开rs文件的，如果打开，那他一定知道这是什么文件了，以及可能遇到的风险，后果自然自负。上传也是一样，直接上传.md文件是无效的，如果云端上传必须改成.md.rs才有效，这样能保证用户对更改是有感知的，知道自己在做什么。
当然，也建议可以通过一些程序去动态修改一些文件，这样的话他必须了解修改的方式及注意事项。比如，如果用户通过程序去修改，还可以生成一个云端的修改log，这样通过多个客户端的log就可以对比修改的文件了。这样既保持了性能，又保持了多种需求的灵活性。
1 个赞
直接用Syncthing同步 
本质是同步，考虑同步数据是不是可视可编辑本身就没道理，那是备份该考虑的事情
比git 好用么？