Windows difyctl deletes the previous file before a failed replacement

快速结论：在 Windows 上使用 Dify 源码版执行 difyctl 写配置或写缓存时，如果底层“先删目标文件再重命名”的原子替换在中途失败，就会出现 Windows difyctl deletes the previous file before a failed replacement 这种旧文件已被删除、替换却没完成的场景。优先排查 cli/src/sys/index.ts 中 win32AtomicReplace 的实现，以及写失败后旧文件是否仍存在。

适用环境：Issue 确认并复现的环境为 Self Hosted（Source），Dify 源码 main 16a2f5abd5727ea05ea5bbaef12c2c6fad5c7435，difyctl 1.17.1，操作系统 Windows，Node 24.21.0；无需 Dify 服务端或凭证即可复现。

最快修复方案：Issue 中提出的修复方向是：移除替换前的预先 unlinkSync(dst)，改为直接使用原生 renameSync(src, dst) 完成替换（依赖 Windows 上 MoveFileExW + MOVEFILE_REPLACE_EXISTING 的覆盖语义）。该方案在同一 Windows 环境下验证过“直接原生 rename 覆盖已存在文件可成功”，但属于 Issue 提议，尚未确认合入发行版。

注意事项：该缺陷是“条件性触发”：只有在删除旧文件之后、重命名失败时才会丢失旧文件，并不代表每次配置写入都会失败或丢失。按评论提示，受影响的不只 config.yml 和 catalog 缓存，凭证走文件存储时的 tokens.yml 也经由 FileTokenStore → YamlStore → FileBasedStore.flush 走同一替换路径，因此同样存在旧凭证文件被删除的风险；调用方的错误处理只删除临时文件并向上抛错，不会恢复原目标文件。另外，分发版 CLI 由 Bun 编译，Node 复现不能完全等同 Bun 运行时行为，建议在 Windows Bun 上再做验证。

问题场景

在 Windows 下运行 Dify 源码版的 difyctl，触发需要临时文件替换已有文件的写入操作时出问题。该替换逻辑由 FileBasedStore.flush 和 catalog 缓存写入调用；Issue 用一段独立 Node 脚本在仓库根目录运行，通过 resolvePlatform().atomicReplace(join(dir, 'missing.tmp'), target) 故意让临时源文件缺失，从而稳定复现“替换失败但旧目标文件已消失”的路径。评论补充：凭证使用文件存储时，tokens.yml 的写入同样经过 FileTokenStore 委派到 YamlStore，再走到 FileBasedStore.flush。

报错原文

replacement failed: ENOENT
existing settings preserved: false

对应标题中的核心描述为：Windows difyctl deletes the previous file before a failed replacement。

原因分析

最可能的原因：cli/src/sys/index.ts 中的 win32AtomicReplace 在调用 renameSync(src, dst) 之前先执行了 unlinkSync(dst)。一旦后续重命名失败，旧的目标文件在上一步已经被删除，于是替换既没有成功、旧内容也无法保留。调用方的错误处理仅清理临时文件并把错误继续抛出，不会把原目标文件恢复回来，因此该路径可能造成持久性数据丢失——但这以“删除之后重命名失败”为条件，不能推断为所有配置写入都会失败。

环境排查

确认 Dify 是否为 Self Hosted（Source）部署，源码版本是否为 16a2f5abd5727ea05ea5bbaef12c2c6fad5c7435。
确认 difyctl 版本是否为 1.17.1。
确认操作系统是否为 Windows。
确认 Node 版本（Issue 复现为 Node 24.21.0）。
确认触发写入的存储类型：config.yml、catalog 缓存，以及文件存储下的 tokens.yml。
如使用发行版 CLI，注意其为 Bun 编译，可另行在 Windows Bun 上确认替换行为。

解决步骤

先定位问题代码：查看 cli/src/sys/index.ts 中 win32AtomicReplace，确认是否存在“先 unlinkSync(dst) 再 renameSync(src, dst)”的顺序。
按 Issue 的复现方式验证：在仓库根目录运行提供的 Node 脚本（使用不存在的临时源文件 missing.tmp），观察输出是否为 replacement failed: ENOENT 且 existing settings preserved: false。
可优先尝试 Issue 提议的修复：去掉替换前的预先 unlinkSync(dst)，直接使用原生 renameSync(src, dst)，让 Windows 的覆盖语义完成替换。
在 Windows 上用真实文件操作回归：分别验证成功替换、首次创建文件，以及“源文件缺失导致替换失败时旧目标文件仍被保留”三种情况。
如使用发行版 CLI，在 Windows Bun 运行时上重复上述验证，确认编译后的行为与 Node 环境一致。

验证方法

复现脚本在替换失败后应输出旧的 settings.yaml 仍存在（即 existing settings preserved: true），同时替换失败错误仍能正常抛出；成功替换和首次创建文件的用例应继续通过。Issue 中提到对未改动生产代码的真实文件测试结果为 6 passed, 1 failed，修复后该失败用例应转为通过。