用remotelysave插件onedrive同步。多平台数据混乱,笔记丢失。怕了。最后发现是onedrive的问题

感谢实践! 请教一下:

前面把主库中少量文件, 软链接出来做为局部库,
然后 局部库+移动库 都开启同步插件, 我看明白了

后面第三条 " 3. 副 Vault ← unison → 副 Vault(copy) <– Remotely save –> 移动端ob "
我理解这是为能做到 “主力PC上不要同时开俩库”,
此外查了下 unison 是 ssh / TCP 的目录同步

但我没想明白, 最后常规使用时, “副 Vault” / "副 Vault(copy) " 这俩目录是啥具体情况? 我猜:

  • “副 Vault” 还是在主力PC上, 但不必以Ob打开
  • "副 Vault(copy) " 是放另一个PC里? 以 Ob 打开, 挂上 Remotely save 放着

是这意思吗? 谢谢

假如按照我上面提到的有这几个 Vault

并且在PC和移动端同时编辑了 1/a.md

上面提到的2就是,B<-remotely-save->C,有两种情况

  1. B中的 remotely-save 识别到 1/a.md 是同时编辑的冲突文件,同步时由 remotely-save 解决冲突
  2. B中的 remotely-save 没有识别到 B/1/a.md 的修改,同步时直接C/1/a.md覆盖
    (这种情况我之前是发生在 Ob打开A库直接编辑 a.md文件,等到打开 B库同步时丢失了A的编辑)

所以我才想将 A中的所有修改对于remotely-save来说推迟到它可以识别,那么就是引入 B_c (就是上面说的副 Vault(copy)),所有文件都是 B库的副本,此时B库其实只是作为方便本地同步工具同步的中间文件夹。实际上所有同步操作都在 B_c 库上执行。

还是上述情况,就变成, B_c 同步移动端的修改,然后使用本地文件夹同步工具(我是用unison),此时unison会让用户处理 1/a.md 的同时编辑冲突问题,解决完再同步到 远端。

从remotely-save的视角,就是 C先编辑了 a.md 文件,然后B_c再编辑了 a.md 文件。于是等到移动端(C)同步的时候,没有任何冲突。

只要ob的同步工具对于情况2可以很好的处理,以及没有其他冲突处理问题,就没必要这样搞了。

不客气,希望能解答你的疑惑。

明白了, 当发生编辑冲突时, 用 unison 之类工具做协调, 比当前的 remotely-save 更合适
谢谢~

这说明了要选择可靠的同步方式。建议阅读中文教程相关章节。

国内的OneDrive还是不行,我转到s3之后就好了,秒同步,用的是阿里云oss,一年9块钱

有群晖(黑白都可)的朋友可以试试配置DDNS (DDNS-GO套件)+公网IPV6+WebDav, 非常快,很稳定的

是onedrive的问题,我现在发现

可以的,是onedrive的问题

以前也是用的OneDrive,其实不完全是onedrive的锅,OD确实响应速度不如很多国内的webdav平台,其次remote的同步机制无法判定优先级,也没有版本管理,我最后还是将同步,交给专业的同步软件去做。

remote用来备份,你需要时刻记得同步,不然异端就会同步上旧的历史
(丢过一个下午的论文记录,血训)

昨天我们在Q群里讨论了一个下午,得出一个结论——任何的删除、修改或者重命名操作,都要在带有Remotely Save的Obsidian里面完成,不能在OneDrive或者文件管理器这些外部做。

否则Remotely Save云端的json不会记录这些操作,同步就会出错。

包括,S3也是一样的,不过S3比OneDrive稳定些。

另外就是OneDrive同步确实慢,不如S3。

密码:Ob 这是群友总结常见的出错原因,可以下载这个PDF继续了解。不过你只要记住我加粗的话就行了。