🔁 WebDAV Sync：通用、稳健的 WebDAV 同步插件（v3 重写已完成）

经验分享
,
21

但是又出现另外一个问题了。
net::ERR_NAME_NOT_RESOLVED

22

Remotely Save一直启动失败，都想放弃了。安装Remotely Sync 后正常了，终于可以愉快的使用了。

23

期待端到端加密功能的加入

24

坚果会已经推出了针对obsidian的同步插件，跟这里装的一模一样，不知道是不是楼主的直接被坚果云买走了 :grinning:，大家可以直接在第三方插件社区里面搜Nutstore Sync 就可以找到了。不要安装BRAT，直接用。

25

webdav v2.3.2已经用了很多天，很稳定好用，谢谢。 :two_hearts:

发现了一个极小的"逻辑"问题，对使用没任何影响，也没有造成任何错误：

  1. pc端和移动端插件，“冲突解决策略"均设为"使用最新版本”。
  2. pc端新建一个"1.md"文档，点击"同步"，上传"1.md"，成功。 :white_check_mark:
  3. 移动端，点击"同步"，下载"1.md"，成功 。 :white_check_mark:
  4. 移动端，如果再点击"同步"，会重新上传这个最新的 “1.md”，这里的"逻辑"不对，正确应该提示"没有需要同步的更改"。
  5. pc端，点击"同步"，会下载 “1.md”。
  6. 移动端，点击"同步"，才会提示"没有需要同步的更改"。

在使用感受上第4步和第5步是多余的，但这是个小问题，没任何负作用… :stuck_out_tongue:

我的猜测：
我没能力阅读插件源代码，虽然表面是第4步有"逻辑"问题，但我猜测是第3步，移动端在下载"1.md"文档时候，改变了文档的“时间戳”或者"某个特征码"，导致和webdav服务器上的最新"1.md"不一致，才会导致第4步重新上传该文档。

26

@di1jiobs: 测试期间未复现此错误。本插件绝不应执行如您所述的冗余同步。请检查在第二次移动端同步前，您是否对 1.md 进行过修改，或者是否有其他插件在笔记创建后自动修改了笔记内容？

@luove512: 需要澄清的事实是：Nutstore 并未“购买”本插件。两款插件均为开源，且 WebDAV Sync（本插件）实际上是由 Nutstore Sync 演变而来。主要改进包括：

  • 重写了大部分内部逻辑（我必须吐槽 Nutstore Sync 的代码堪称“屎山”）。
  • 实现了通用性。
  • 提升了安全性（使用 Obsidian Keychain 存储凭证，而非将密码明文存储在文件中）。
  • 修复了一些关键 Bug。
  • 大幅提升了性能（体积缩小 92%，对于没有速率限制的 WebDAV 服务，同步速度比 Nutstore Sync 快 50 倍）。
  • 增加了更多功能与选项（例如 Nutstore Sync 目前不支持同步 Obsidian 配置，而本插件支持）。

@Thehone: E2E 加密似乎是许多用户的迫切需求。我认为拖延毫无意义：若一切顺利，v2.4 版本将侧重于稳定性提升和用户体验优化，而 v2.5 版本将包含 E2E 加密功能。未来几周的插件开发进度可能会稍慢，因为我个人目前工作繁忙。感谢理解。

1 个赞
27

不好意思，我没有改动过1.md，我把其他所有插件关闭，一个个打开测试。
最终发现不是WebDAV Sync问题，是Templater插件的问题（设置打开了"Trigger Templater on new file creation"选项，关闭这个选项就没这个问题），我发帖时候用的是Templater v2.19.0，更新到 v2.19.1，问题依旧。

1
1979×528 32.2 KB

奇怪的是我查看了1.md的内容，Templater没改动任何内容，经过检查是改变了文档的"修改时间"。 :sweat_smile:
比如：
在pc端1.md最后修改时间是：21:47分
在移动端，同步，把1.md下载回来，发现最后修改时间是：21:50分 (即同步时间)

1.md有内容的不是空文档，也没给它设置"Templater模板"。
很奇怪，Templater怎么会在文档"下载"成功后，没有改变内容，单独改变它的"修改时间"，我也不用github，不知道怎么向Templater反馈问题。。

28

老师，这个同步必须要挂梯吗？一直显示“检查连接”

29

:stuck_out_tongue: 问题解决。

我用deepseek分析了Templater插件的问题，还真找到了，但我不太会编译.ts文件，我直接修改 plugins\templater-obsidian\main.js 这句代码：

await e.overwrite_file_commands(n)

改成

console.log("好像是负作用代码，已删除")

完美解决问题！我看了ai的分析，貌似这行代码并没实际作用，删除后少了这步，速度还快了一些。
否则，每同步一个新文件就执行一下这个方法，反而导致有点卡顿。

:bulb: deepseek分析如下

事件监听注册 (EventHandler.ts)：
在 EventHandler.ts 的 update_trigger_file_on_creation 函数中，通过以下代码监听了所有文件创建事件：

this.trigger_on_file_creation_event = this.plugin.app.vault.on(
    "create",
    (file: TAbstractFile) =>
        Templater.on_file_creation(
            this.templater,
            this.plugin.app,
            file,
        ),
);

app.vault.on(“create”) 是 Obsidian 的底层 API，它不仅会在你新建文件时触发，当文件通过同步、复制等方式首次出现在仓库时同样会触发。

文件处理逻辑 (Templater.ts)：
事件触发后，会调用 Templater.on_file_creation 方法。尽管该方法开头有template_folder 过滤逻辑，但对于普通的、内容不为空且不在模板文件夹内的文件，它最终会执行：

// Templater.ts 的 on_file_creation 函数中
await templater.overwrite_file_commands(file);

这个 overwrite_file_commands 方法会解析文件内容中的模板命令，并调用 Obsidian 的 app.vault.modify(file, output_content) API 来写入文件。

问题的直接原因：
这个 app.vault.modify 调用就是修改时间戳的元凶。即使文件内容因未找到模板命令而没有任何实际更改，调用此 API 本身仍会向 Obsidian 发出一个“文件已被修改”的信号，导致操作系统更新文件的“修改时间”为当前时刻。

30

不用。那是和webdav服务器连接有问题

1 个赞
31

感谢耐心解答，找到了问题关键。谢谢

32

大佬牛逼，我以前使用remotely save的时候就发现同样问题，第一次看到了问题来源

33

感谢作者的工作。
想问一下，目前插件的同步速度如何？之前使用的remotely save插件搭配infini-cloud服务，3000左右文件的库同步速度大概在十几秒到二十秒左右。这可能是remotely save代码过于庞大冗杂导致的。不清楚作者的插件整体的同步速度如何？

34

emmm……应该与你的网络速度有关

35

回复：

@di1jiobs：我看到了与 Templater 的兼容性问题。不幸的是，最后修改时间是大多数同步插件用来判断文件自上次同步以来是否被修改的关键指标。你的描述完美地解释了这一故障。我已在 GitHub 上向 Templater 提交了 这个 issue。希望他们能早日解决。

@RobertKidder：随着 v2.4 版本的发布，我已经将所有可能的任务并行化，插件的性能已推向极致。剩下的瓶颈仅在于网络连接速度和你机器的原始性能。根据你的描述，很难估算执行同步所需的具体时间，但我可以提供一些数据作为参考。假设你拥有舒适的 WebDAV 连接速度（>= 10MB/s 或 >= 80Mbps，延迟低于 100ms）并且使用的是电脑：

  • 下载包含 3000 个文件的整个仓库：2-5 分钟
  • 仓库中有 3000 个文件，但只有 10 个文件需要同步：10~20 秒
  • 仓库中有 3000 个文件，但只有 10 个文件需要同步，且启用了 彻底远程遍历 并且你的服务支持该功能：5 秒
  • 仓库中有 3000 个文件，但只有 10 个文件需要同步，你触发了实时同步并启用了 实时同步快速模式：2 秒
36

感谢 ，耐心帮助和提供好用的插件

37

是只支持webdav吗？请问什么时候能像remotely save一样支持阿里云存储呢，谢谢

38

@linwqwhu：不确定你提到的 阿里云存储 是指阿里云对象存储（兼容 S3）还是阿里云盘。如果是前者，我有一个长期计划来支持 S3 及兼容 S3 的存储服务，就像 Remotely Save 所做的那样。目前，插件代码具有很高的可复用性，适配 S3 并不困难。如果是后者，则在近期不会考虑支持。

我需要一次投票来确定支持 S3 的计划是否值得。我建议所有看到此消息的朋友参与这个只需 5 秒的匿名投票，以便我获得公正的结果，无论你对 S3 是否感兴趣，谢谢 :heart:！

适配 S3 的优点：

  • 你可以使用自己的 S3 服务进行同步
  • S3 在理论上比 WebDAV 更快、更可靠
  • 现有的同步逻辑将被复用，你将获得类似的插件体验

适配 S3 的缺点：

  • 需要更多的开发工作量，并可能引入潜在的 bug
  • 略微增加开销：S3 对 WebDAV 用户无用，反之亦然，同时包含两个后端会增加加载时间

请注意，除了 WebDAV 和 S3 之外，所有专有协议和厂商特定 API（OneDrive、Google Drive、阿里云盘）在近期均不在计划之内。它们会给插件带来净开销，却只惠及少数用户。

  • 我正在使用 / 计划使用 S3 服务，很高兴看到支持 S3
  • 我不了解 / 未使用 S3，仅 WebDAV 已满足我的需求
0 投票人

此投票也可在 GitHub 此处 参与。

39

remotely save有一个问题就是集成了太多同步协议，但用户一般只会用到其中一种，这造成了很大的冗余，严重影响了启用速度。在桌面端可能不明显，但在移动端，remotely-save插件和作者的webdav插件启动速度差了十倍以上（前者600ms以上，后者50ms左右）。
另外，单个插件过多的同步功能可能也是remotely save作者后续难以跟进维护的原因之一。
更希望作者将不同协议的功能区分开来，不同协议打包为不同的插件。将通用的功能模块，作为通用的库，被不同的同步插件所调用，这样也能一定程度提高复用性，减少多个插件开发的复杂程度，不清楚在TypeScript开发中这是否能很好的实现。

1 个赞
40

加密功能已在 v2.5.0 版本中发布。本插件采用的加密机制比 Remotely Save 更为安全。@Thehone

使用提示：只有当所有设备上的以下四项内容完全一致时，加密才能正常工作：

  • 加密密码
  • 服务器 URL
  • 账户名称
  • 远程基础目录

一个常见的坑是：在桌面端将服务器 URL 设为 http://localhost:<port>，而在移动端却设为 http://192.168.0.<主机 ID>:<port>。这种不一致的配置在启用加密时会导致失败。请务必在所有设备上统一使用 http://192.168.0.<主机 ID>:<port>。

@RobertKidder：没错，你的担忧非常合理，值得强调。另外，在 TypeScript 开发方面，我们有一套完整的标准体系和工具链来保障代码复用性和开发效率。

不过，我似乎想到了一种更明智且巧妙的方案：通过 JavaScript 模块加载机制，按需加载独立的驱动模块。虽然尚不确定能否完全实现，但一旦成功，插件将能在不增加任何冗余体积的前提下，理论上支持无限数量的后端存储。这种模块加载技巧以及其他多项突破性优化已纳入 v3 版本的规划。总的来说，v3 版本将带来：

  1. 显著更快的同步速度。
  2. 近乎无限的后端支持，且零冗余。
  3. 更加安全的加密机制（目前的安全性已优于 Remotely Save）。

这将是迄今为止最大的一次重构，当然也需要投入大量的精力。

趣闻

似乎 Nutstore Sync 的开发者被上级剥削，在一个同步插件中加入毫无用处的 AI 助手，结果导致插件体积膨胀至原来的 5 倍，加载和同步时间也大幅延长。看戏中。（不过我还是要对他们的开源精神表示赞赏，尽管本插件中保留的他们的旧代码已经所剩无几）