楼上有同学说的增量同步，应是基于同步盘的实时同步。
RS的机制显不适用。
就如使用goodsync等双向同步工具，冲突是需要自己解决的，要么旧盖新，要么下行，要么上行，在这之前，对个别自己很明确有可能两边有新信息的，就要通过左右两边查看，把信息归集到一边，才覆盖同步。
那么RS该如何最好？
一是能结合OB的恢复镜象机制，在保留一份最新的基础上，把本地较旧的送入恢复镜象里，在发现信息缺失时，去恢复镜象里找回。
二是建一个下划线的专用目录，如_RS，把云端和本地较旧的版本下载一份到_RS里，同时用原文件名_timestamp来命名，也是交给本地用家解决冲突。由于RS缺省是不上传_目录，也不会污染环境。
使用RS，我碰到的危险事件，还有 僵文复活 和 活文被删。
针对后者，所有本地删除的文件，也统一放入_RS/DEL里，由用家自行清空。
针对前者，应是同步机制逻辑缺陷，需要修复。
使用goodsync把整个库同步到安卓手机上，比较过，所有文件的创建和修改日期都是一致的。但在手机上执行rs同步时，却提示几乎所有的文件都要重新和云端同步。
手机和电脑比较，是无意义的。你要和云端（比如说onedrive）比较。可以导出同步计划自行查看，100%是修改时间不一致。此外这里要明确用什么云。此外接下来的版本会尝试加入适量hash 机制来尝试回避此问题
去 github issue 提交可复现 bug 哈。文件被删除，目前看逻辑是 100% 有一端被删除了。
github 有时能访问，大多时候又不成。所以，无注册用户。
我明白你是指timestamp上不是绝对一样！
但同步软件不都是这样弄的吗？对人的操作来说，精确到hh:mm:ss的比较就足够了吧？
要么加个开关，允许低精度比较（如同步软件那样）？
就昨晚创建的新库。
win exec rs
win — goodsync — android (它是创建日期和修改日期都同步）
android del 1 file
android exec rs , prompt exceed 50%
android set 100% sync
android 把删除的文件也弄回来了。
是因为云盘不能设置实际的创建日期和更新日期吗？我看云盘上的日期都设为上传时点了，但我的操作都是在上传时点之后，逻辑上说不清。
我看云盘上有个_线的目录，这是元数据吗？
rs是用自己的元数据机制，重现文件日期结构吗？那么直接用元数据比较，应该能兼容各种同步软件啊。
时间戳就是秒级别的
时间戳就是秒级别的
那应该可以如 goodsync这类软件的同步机制。
有个疑问，rs同步下来时，不管是win还是android都不能如实时修正文件的创建时间和修改时间，都变成同步时间。是因为技术上不能如同步软件那样修改两个时间，还是一开始就没有考虑好呢？
这就人为导致同步逻辑变得复杂不可控了。
win 用 rs 同步到 webdav，这时候 webdav 只有上传时间，无法保留文件真正修改时间，win 本地记录了修改时间和上传时间的映射。这是 webdav 本身的缺陷，无法规避。
win goodsync android，goodsync 把修改时间复制到 android 了。
android rs 同步 webdav，这时候问题来了，本地修改时间和云端上传时间不一致，插件之前也没有运行，因此也没有存储他们的映射，因此会触发全量更新。你想想，插件在 android 上是看不到电脑端信息的，他只看到云端信息。
假如只用 rs 的话，第二步 android 上假如原始是空的话，那么会自动下载一次，并把服务器的上传时间作为 android 侧的修改时间，之后的同步也不会出问题。
根本问题是你混用了两种同步方式，插件不兼容。且插件并不是比较手机和电脑，而是分别和云端比较的。我强烈建议不要混用。
此外下划线文件问题，看你是设置了加密，可能是刚好加密名字有下划线开头。
此外插件目前没有独立上传额外的元信息文件到云端。
双端都用 rs 同步一次之后，以后的任意一端删除都可以正确跟踪和处理。
Remotely Save 同步机制建议
我在安卓端运行webdav service，再用goodsync同步，是能完整把创建和修改日期复制到安卓端的。
webdav运营商的服务倒未试过goodsync的同步效果。
既然重构，来个彻底些，向同步软件的机制靠拢，以安全为前提：
云端构建 yuncreated() 取得和设置创建日期， yunmodified() 取得和设置修改日期
filelistYunLocalunexist() 云端存在但在本地不存在的文件列表，且剔除云删表的文件，称为增加表
本地构建 filelistDelFromLastsync() 取得本地上次同步之后，删除的文件列表，称为云删表
同步逻辑：
云删表，下载云端文件到 _rs/yundel/filename_timestamp，删除云端文件
本地文件列表，yunmodified()=localmodified() && size一致，pass; yunmodified > localmodified && localmodified> locallastsynctime 冲突，本地文件移至 _rs/localvol/filename_timestamp，同时下载云端文件覆盖本地，本地两个时间设为云端;
yunmodified<localmodified && yunmodified>locallastsynctime 冲突，去端文件下载至 _rs/yunvol/filename_timestamp，同时，本地文件覆盖云端，云端两个时间设置为本地；其他情况，最新覆盖最旧，并把文件时间更新为另一端时间。
最后处理增加表，yunmodified()>locallastsynctime，新增，云端下到本地，时间一致；否则，视为此前岁月删除了，下载云端文件至 _rs/yundel/filename_timestamp，删除云端文件。
同时，也简化同步日志，输出一份内链清单，分五部分：
### 本地删除
[[_rs/localdel/....]]
### 云端删除
[[_rs/localyun/....]]
### 冲突
[[_rs/localvol/....]] <-> [[filepath]]
[[_rs/yunvol/...]] <-> [[filepath]]
### 本地新增
[[filepath]]
### 本地更新
[[filepath]]
测试了
goodsync不能连接infiintsync，但可以连接koro，虽然在koro的前端只看到最近更新。
但goodsync 显示的时间，两边是一致的，再同步，也没有提示有修改：
是否说明webdav也是可以设置创建日期和修改日期的？
更正
webdav服务应该是不能设置日期的，goodsync显示的日期，只是他构建的元数据里的日期，把元数据目录删除后，刷新，显示的文件日期就变成今天了：
是的，目前的机制，只适合两台机，频繁同步。
我试过，好久无同步，一同步就乱套了，把已删除的一大堆文件都给我重新下回来，还不知道下了那些，更新了那些。
建议目前机制，也如我上面的建议那样，所有的删除，都在本地保存一份备件，同步计划也改成我建议的，一目了然且方便追踪更改。
是啊，如你所说，事情并没有那么理想。
我们是假定云盘只有存储功能没有运算功能，因此这个构建并不是一定可以构建的。此外目前也已经通过修改时间和上传时间达成了这个机制。
不会的，这里只是因为你混用了同步软件。你想想，对于程序来说，隔1天和100天的运行逻辑都是相同的。
这也不是显然的，很多人存储了大文件，几十 mb 几百都有
放几十MB的文件，少数吧。
ob就是用来信息归集和重现的，关键要降低使用成本。
担心文件丢失，就是一种成本。
如你所说，要提前备份，最好的备份就是用备份工具，但一不小心又可能导致逻辑矛盾。
一种策略，要想到，当版本稳定后，不管多少岁月，用家都不用再刻意留意那些坑，不管怎么同步，资料总还在。
要不加个开关，给用户选择，就多点代码保留删除和冲突，就如同步工具那样，冲突要归用户自己解决，解决好，就把_rs目录删除就成了，也不占地方。
我是说，如goodsync那样，在云盘放上点元数据，运算当然是在本地。逻辑清楚，就好办。
机制仍是可麻烦。
win ob， rs
win ob 数据目录单独拿出来 （一烦）
win 无数据的ob send to android or ios (二烦） ，现在是使用sendanywhere，应该用goodsync也可以，但为这个临时的建个Job也是麻烦
android ob rs
碰到的问题：目录结构不完整，媒体目录、数据目录、日记目录，没有Jpg或md文件，就没有同步下载，即使已在这些目录里建了.nomedia文件，也没有同步，之后也没有同步这个.nomedia，这个文件是让手机不干扰ob里的文件的。
这又是什么……这个我的插件不识别这个文件的喔。
假如全程建立用 remotely save，只需要一次上传一次下载就对齐了啊，为什么要这么多工具搞得这么复杂……
