D

思源自身是不会写坏数据的，这种情况多半是使用过第三方同步盘或者有其他软件读写文件造成的，只能通过之前的备份数据恢复。

最近一次报错记录：

E 2024/10/20 20:43:17 sync.go:586: sync failed caused by network: RequestError: send request failed
caused by: Delete "https://siyuan.nas.yljyl.top:9000/repo/lock-sync": dial tcp: lookup siyuan.nas.yljyl.top: no such host

后面同步都是正常的，没有报错。如果使用了主题、插件或者代码片段，建议都关闭后再测试。

应该都是一个问题。

删 0 KB 的文件就行了，其他文件还是可以读取的。

对的，这些文件都是损坏文件，已经没有任何数据了。

在 设置 - 关于 中导出系统日志

我这里正常，你可以上传一下日志吗？

zookeeper 这个笔记本里面有一些损坏文件，0 KB 大小这些都是损坏的，你手动删掉吧：

这些损坏文件会造成目前思源内核异常挂起，下个版本会修复这个问题 Issue #12852 · siyuan-note/siyuan 感谢反馈。

收到，我这边调试完后回复你。

再上传一下系统日志。

肯定不需要那么久，从日志中看你那里只有 228 个文档，27199 个块，这个量级正常的话重建索引应该可以在 1 分钟内完成吧。

你再试试删除 工作空间/temp/ 文件夹后启动思源，如果建立索引还是很慢，可能是其他问题。如果方便，请把 工作空间/data/ 文件夹打包发给我测试看看 845765@qq.com

设备性能不足的话正常，思源对系统硬件资源要求较高。

帖子里面下载就可以了，或者你重新在 设置 - 关于 中导出一份。

资源文件建议统一保存在 工作空间/data/assets/ 下（并且使用 assets-id 格式），否则会有一些副作用，具体细节详见 用户指南 - 资源文件 章节。

关联 复制粘贴不停崩溃

日志指的是你之前上传的系统日志，解压以后用记事本打开里面的 siyuan.log 查看，然后搜索我刚刚说的那两个关键字就可以找到损坏文件的路径了。

重建索引入口位于 文档树 - 更多 菜单中，你截图的这个是重建文件历史索引，不是重建数据索引。

从日志上看有的文档数据已经损坏，在日志中搜索关键字 parse json 和 properties not found 可以找到这些损坏文件，把所有损坏的文件拷贝到其他地方后再启动思源，然后重建索引。

其中损坏的文档数据时间有很多是 2023 年 6 月份，可能是这个月使用了第三方网盘同步导致的。

另外，不建议在机械盘上使用思源，否则性能会比较差。

试试手动安装 pandoc，然后在 设置 - 导出 中设置 Pandoc 可执行文件路径 为你手动安装的 pandoc.exe

大概有两种可能：

1. 没有 Downloads 文件夹写入权限
2. 待写入的文件被其他软件打开占用了

不考虑标签和引用功能重叠，这个 issue 稍后会关闭。

抱歉，标签不会考虑改动了。

欢迎在社区发起一个投票贴来帮忙统计，我们置顶一段时间。

等后面继续收集需求再考虑吧，现在还有很多比这个重要的任务待开发，谢谢。

如果这两种模式的需求都较多，那么会考虑加开关的。但目前来看并没有，所以暂时不动，继续收集反馈，谢谢。

我的意思就是不把子块包含在内，但是要改这个逻辑要先看社区反馈，我们不能轻易改动。

包含子块的好处就是一目了然，在父级就可以看到所有引用处，不用聚焦。

那可能是因为 rr 在同时引用父块和子块的情况下会把子块去重不计入反链，我们是否要这样做还需要讨论，目前不会轻易改动这些逻辑了，谢谢。

我不懂你意思，麻烦截个对比图说明吧。

那如果 b 块又引用了 A 中的块呢？脚注定义中跳转正文逻辑不对，所以现在统一为脚注。

如果需求多了会考虑处理这种特例情况，转换脚注的方案是目前通用的最优解。

那混合的时候咋办？而且是无法区分混合情况的，因为可以递归引用。