请支持无法使用硬连接(hard link)的文件系统

[SwimmingTiger]

并不是所有文件系统都支持硬连接，或者当前用户也不一定有权限创建硬连接。
比如HarmonyOS内的用户就完全无法创建硬连接，我们只能得到以下报错：

本轮运行失败EACCES: permission denied, link '/storage/Users/currentUser/.dsh/sessions/--storage-Users-currentUser-work-wine-WineHua--/session-207ab6ad-2f89-445f-8e60-c11b72a2de56/session.jsonl.zstd.55acf2760149.tmp' -> '/storage/Users/currentUser/.dsh/sessions/--storage-Users-currentUser-work-wine-WineHua--/session-207ab6ad-2f89-445f-8e60-c11b72a2de56/session.jsonl.zstd'

分析代码可知硬连接只是为了把临时文件做原子发布，然后临时文件会被马上删除，似乎改成rename也没有影响。
希望可以在硬连接失败后退回使用rename，uuid冲突的可能性是很小的，这种超小的文件被覆盖风险完全可以接受。

其实我已经为我自己创建了一个补丁来解决这个问题：
https://gitcode.com/hu60cn/ohos-script/blob/master/ohos-patch-dsh-hardlink.sh

方法是编写一个 fs.link 函数的替代品来进行回退（为了保证语义我只能回退到copyFile），目前它在我的电脑上工作良好。
所以看起来 deepseek harness 并不需要硬连接的“两个路径一份内容”这个语义，那退回 rename 或 copyFile 是完全可行的，至少比彻底用不了好的多。

import { constants } from "node:fs";
import { copyFile, link as systemLink } from "node:fs/promises";

export async function link(src, dest) {
	try {
		return await systemLink(src, dest);
	} catch (error) {
		if (error.code !== "EACCES" && error.code !== "EPERM") throw error;
		return await copyFile(src, dest, constants.COPYFILE_EXCL);
	}
}

export * from "node:fs/promises";

[denial123789]

I traced this against the rc.7 persistence code. The hard link is not only avoiding a copy: it provides complete-before-visible publication and a no-overwrite race boundary. Ordinary POSIX rename() can replace an existing final log, while copyFile(..., COPYFILE_EXCL) avoids overwrite but can expose a destination before copying and syncing finish. A global fs.link shim therefore changes a storage invariant.\n\nI published an English operator runbook that separates this from pnpm and generic settings-file errors, includes a same-filesystem capability probe, and gives two safe current recovery paths: move the full DSH home, or override only session-persistence-jsonl.config.root to a tested local filesystem after quiescing all writers. It also lists twelve acceptance gates for an upstream fallback:\n\nhttps://sandbaseai.github.io/deepseek-harness-handbook/session-hard-link-unsupported.html\n\nThe key upstream requirement is a cross-process no-clobber publish protocol with atomic reader visibility, directory durability, cleanup, and crash/concurrency tests on a filesystem that rejects link().

[SwimmingTiger]

在HarmonyOS上目前找不到可以创建硬连接的文件系统，因为SELinux规则阻止用户创建硬连接，即使f2fs原本支持硬连接也无法创建。
如果deepseek harness坚持使用硬连接，我们只能继续使用第三方兼容性补丁将其修改为copy或rename。
我想说的是，这种修改目前在我的电脑上工作良好，并且碰撞和提前暴露的风险完全在可接受范围内，让它工作总比完全无法工作好。

[SwimmingTiger]

作为用户，如果会话真的因为碰撞损坏了，那我直接删除掉会话就行了，没什么大不了的。但如果所有会话都不能开始，那我就什么都没有了，对我来说显示是更糟糕的。
还有，为什么会有两个进程实现同一个uuid？只有随机数生成器有Bug的时候才会发生这种现象，我们在现实中很难真的遇到这种现象。
还有，作为用户，我们为什么要尝试在同一个主目录中启动两个dsh进程？我们不会这么做的。我们也不会在会话尚未发布之前刷新网页，所以提前暴露的风险对我们也没有意义。而且就算网页加载到了不完整的会话，那我们刷新就是了，对用户来说需要刷新是很常见的现象，并没有什么大不了的。对原子发布和碰撞预防的坚持对一个默认监听在127.0.0.1并且通常由单人使用的服务来说意义并不明显。

[SwimmingTiger]

也许可以把所有文件都存在sqlite数据库里，然后虚拟出一套文件系统API来用，这样应该可以实现原子发布和避免暴露