跳到主要内容

AFS

运行时边界

区分 mount、权限、实例状态、本地验收与正式发布，避免巡检意外改写用户环境。

AFS 行为始终是实例形态的。同一 CLI 二进制面对两个 daemon、两套数据目录或两张 mount 表，不会产生相同路径。

除非另注，均在 arc 2.0.0-beta.28 对本地 daemon 核验。

Mount

事实细节
Mount 把路径前缀绑到 provider URI形状示例：/modules/project -> fs:///absolute/path
列出 mountarc afs mount list / arc afs explain mount
校验配置形态arc afs mount validate → 核验主机上为 Configuration is valid
密钥URI 可能含凭证（token、vault 路径）。分享前脱敏

mount add 不是自动的验收路径

在 beta.28 上观察到：

  1. arc afs mount add /modules/… fs:///tmp/… 打印 Mounted …。
  2. arc afs mount list 出现新行。
  3. arc afs explain <path> 报告 TYPE unknown。
  4. ls 为空或连接错误；read 为 not found。
  5. arc afs mount remove <path> 清除列表项。

不要写「add 完立刻 write 一定成功」的通用 recipe。优先：

  • 巡检已经在提供数据的 mount，或
  • 使用团队已端到端验证的隔离流程（独立数据目录 / 服务实例），变更前再用 stat/ls 确认。

权限与访问

层约束什么
Provider accessModereadonly / create / append / readwrite
visibilityfull vs meta（meta 拒绝 search 内容）
Action 严重级别 / 策略哪些 exec action 可运行
调用方 / 网络门控部分 mount 上的认证与 network-read 规则

根上列出 write action，也不等于每个子 mount 可写。

实例状态

状态种类例子文档含义
进程主机 AFS 数据目录下的 daemon PID/portCLI 通常连这个 daemon
Mount 表已配置的 provider URI随环境而变
Provider 数据fs:// 下文件、vault 内容、远程资源变更会改真实数据
Blocklet / space 数据本地 DID Space 树属其他 board；勿当可丢弃

不要把任意长期运行的 daemon 当一次性测试基建。会注册 mount 或写入 provider 数据的命令，需要刻意的隔离方案。

本地验收 vs 正式发布

面证明什么不证明什么
对本机 daemon 的 arc afs …本实例的路径/操作/mount 行为全局产品默认、多租户部署
本地 blocklet 服务 / 浏览器（站点文档）文档页渲染你的应用的远程 DID Space 托管
arc deploy / DID Space 发布任务是部署时的发布集成单独证明本地 AFS 合同正确
ARC monorepo 中的 provider conformance某 commit 上的接口纪律你主机上的 mount 等于该 provider

对本 AFS board，本地巡检与 recipes 是主证据。正式发布是另一套清单——仅在任务是部署时使用。

实用检查单

  1. 记录 arc --version。
  2. 在弄清 mount 与能力前，优先只读命令。
  3. 有则读 <mount>/.meta/.capabilities。
  4. 只在自己拥有的 mount 上变更；清理可丢弃路径。
  5. 分享输出前脱敏。
  6. 命令失败时保留精确错误——不要编造成功输出。