问题描述
如上图。我从别处导出一个名为 fp.sy 的压缩包文件，然后把它导入到另一个 siyuan 客户端，导入步骤是：我先在 siyuan 客户端中新建笔记本，命名为 fp；然后导入 fp.sy 的压缩包到该笔记本
出现如下问题：
在新的 siyuan 客户端中，调整 fp 笔记本下的文档排列顺序，然后出现上述图中的文件已存在问题；
但是，在该 fp 笔记本中新建文档，然后移动新建文档，不存在“文件已存在的问题”。
导入的.sy 文档后，移动文档（为了排序），出现文件已经存在的问题
本贴最后更新于 614 天前，其中的信息可能已经事过境迁
1 引用
4 操作
fengjiannju
在 2022-11-16 14:59:21 更新了该帖
fengjiannju
在 2022-11-16 14:56:14 更新了该帖
fengjiannju
在 2022-11-16 14:54:16 更新了该帖
相关帖子
-
fengjiannju • • 1
补充说明：我认为是 linux、docker 版文件处理机制问题，理由如下
现在的情况是：siyuan2 客户端部署在 linux mint 上的 docker，而移动文件排序产生“文件已存在”的问题。【这个问题产生的原因：就是我有两个 siyuan1、siyuan2 运行在 docker，且他们的工作空间是独立的。我在网页端把 siyuan1 的文件导出，再到网页端导入到 siyuan2】
如下图所示，我在 siyuan2 客户端把 2022-11-11 文档移动到 2022-11-14 上方，立马报错，来回移动两个文件顺讯，一直报错，但是文件顺序的确能移动了。只是不爽！
随后做了如下测试：
将 siyuan2 的数据同步到云端后，关闭容器：sudo docker stop siyuan2。
再在 win10 上安装全新的 siyuan 2.5.0 客户端，，从云端同步数据库，同步完毕后，win10 客户端移动同样的文件：将 2022-11-11 和 2022-11-14 来回移动顺序，不会出错——不会出现“文件已存在”的问题。如下图
同步，退出 win10 siyuan。在 linux 上，再 run 一个新的 siyuan3 客户端（开辟全新、独立的工作空间），导入秘钥、并把云端数据同步下来，再来回移动同样的文件的顺序（2022-11-11 和 2022-11-15），又出现文件已存在的问题。
综上，我认为原因可能是：
- docker 客户端下，与移动文件进行排序相关的文件处理过程有错，与 win10 下的处理过程不同，即 win10 的正确，docker 或者 linux 的有错
- 或者与移动文件进行排序相关的文件处理过程没错（win10 docker linux 都正确），但是 docker、linux 客户端会误发出“文件已存在”的警告，而 win10 版本不会发出警告——即，当对文件进行移动排序时，如果文件实际存放位置没有发生变化，则此时 linux、docker 客户端的底层的文件操作函数返回“文件已存在，移动失败”（但不影响 siyuan 文档树内的文档排序调整结果），而 win10 系统下的底层文件操作函数不会发出警告。
1 回复 - 其他回帖
-
-
刚才我又试了一次，还是有 bug
我认为，背后原因可能是，我导出的内容，有跨笔记本引用。
我导出的 siyuan1 客户端中的 fp 笔记本，但是 fp 中某些笔记引用了 siyuan1 中的其他笔记本中的内容。这样把到处的 fp 导入到 siyuan2 客户端：可能导致上述问题，
另外我还发现，导入到 siyuan2 中的 fp 笔记本内的某些文档丢失名字，成为 Untitle。
担心将来索引效率问题
我想导出，是因为担心数据量越来越大后，影响索引效率。
请教下，如果未来数据量太大，我还想保持高速索引，可以通过使用更强大的 cpu（多核心、更高主频）和更大内存来并行查找索引中内容来提高效率吗？
我粗略了解一些数据库索引原理，关键就是在内存中查找数据。那理论上性能更强劲 cpu 配合更大内存，可以解决索引问题？
如果我的想法正确，那我就不使用导出功能了，将来数据量太大影响检索效率，上更强劲的 cpu、更大频率更高的内存即可解决，就不用把数据分拆到好几个 siyuan 客户端了。我现在用着索引太爽了，就怕将来不爽了痛苦。所以现在就得想好到底是把数据分开来，还是将来上更强劲的硬件。
1 回复 - 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于