问题描述
如上图。我从别处导出一个名为 fp.sy 的压缩包文件，然后把它导入到另一个 siyuan 客户端，导入步骤是：我先在 siyuan 客户端中新建笔记本，命名为 fp；然后导入 fp.sy 的压缩包到该笔记本
出现如下问题：
在新的 siyuan 客户端中，调整 fp 笔记本下的文档排列顺序，然后出现上述图中的文件已存在问题；
但是，在该 fp 笔记本中新建文档，然后移动新建文档，不存在“文件已存在的问题”。
导入的.sy 文档后，移动文档（为了排序），出现文件已经存在的问题
本贴最后更新于 740 天前，其中的信息可能已经事过境迁
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 回复 -
fengjiannju • • 1
再次补充说明
经过我再次测试，发现：
docker 端通过网页，问题根源是：如果被移动的文档下面还有子文档，则会提示、警告“文件已存在”问题，该提示、警告不影响文档移动、排序。如果被移动重排序的文档下方没有子文档，则不会提示、警告“文件已存在”
上述问题，win10 桌面客户端不存在。
1 回复 - 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于