Repository navigation
[P1][Storage][Enhancement/Fix] 自动本地每库路由、稳定 repo_key 与 CE 原生库兼容 #33
Description
目标与职责（Server）
在 Seafile CE14 Repo/Commit/FS/Block 基线上，补齐 V2 自动本地每库存储的稳定 repo_key 与原生库兼容；默认只需一个已挂载父目录。这是现有代码的收敛/修复，不是重新设计存储引擎。
现有实现
common/cf-v2-storage.c：cf_library_storage(repo_key,repo_id,state)+ 原生RepoStorageId，目前默认 UUID key，cf_v2_store_dir()分派实际目录。common/cf-storage.c的历史cf_create_repo_json()明确拒绝显式repo_key；cf-auto-storage.h和 Go fileserver 已有部分约束。- 原生 CE 既有库、虚拟库、Trash/GC 保留原生对象语义。
待完善（仅 Roadmap / 未授权开发）
- 新库默认
repo_key=repo_id；按实际有需求的受信建库/导入入口允许显式稳定 key，限定合法字符、唯一性、不可变与 retired 不可复用，禁止任意宿主路径。 - 在首次 Commit 前原子确定
RepoStorageId=auto-local:<repo_key>和唯一cf_library_storage；确保 C/Go/GC/fsck/恢复同一路由。不要恢复退役cf_library_storage_key表、第二套路由真源或cf_managed_library。 - 原生 CE 原地升级默认保留旧库
seafile-data/storage物理对象、Repo ID、Commit/history/trash/共享，native-<repo_id>仅用于登记；虚拟库读取 origin Repo 对象，不复制底层块。 - 路由损坏、目标根丢失、事务不完整应拒绝 I/O，不允许静默回退错误目录。复用 Seafile 原生 GC/fsck/迁移工具，单独核对独立存储根的离线发现/恢复。
验收
- 新装默认 key、可信显式 key、多个库隔离、并发/失败回滚、retired/recover；真实 C/Go/GC 读写对象一致。
- 旧 CE 库升级前后 Commit/文件 SHA/历史/虚拟库不变且无需搬迁；原生存储与 auto-local 库并存。
- 明确缺失项与实测范围；不以单测冒充可部署/可恢复。
代码参照：cf-v2-storage.c · Go 路由。通用模块的实施需单独批准，Issue 不自动触发代码更改。
跨仓协作（仅公开通用工程 Issue）
- Hub API / storage inventory：issues #68
- Docker 升级/部署验收：issues #33
- Server 本地路由性能后续：issues #34
各仓维护自己的实现/验收，任何交叉协调不新增私有项目依赖。
2026-10-24 20:25 关联 PR 状态（已关闭核对）
- Server #36 已关闭未合并（11:54:48Z，Draft）；由 Server Draft #38 接替：UUID 外层目录 + 原生
RepoStorageId决定位置，cf_library_storage仅写 UUID 安全标记。 - Hub 侧 Hub #70 已关闭未合并，接替 Hub Draft #79；Docker Draft #42。
- 状态：保持 Open。已关闭 PR 的显式稳定
repo_key方案未合并；现有 V2 UUID 默认与旧 CE/V2 目录兼容仍待真实 CE14 RPC/GC/fsck 联验。
Activity
servicememeai commentedon Oct 24, 2026
已提交实现切片 Draft PR #36：可信显式 repo_key、默认 CE UUID 路径、初始 Commit 前唯一存储绑定。静态 CI 已通过；需与 Hub PR #70 联合验证、真实 C/Go 构建、冷 GC/恢复后再考虑合并。
servicememeai commentedon Oct 24, 2026
本轮存储审查补充：空映射直接回退 CE 原生目录，需要界定其合法性。
当前
common/cf-v2-storage.c::cf_v2_store_dir()对RepoStorageId与cf_library_storage双空直接返回原生目录，Gofileserver/objstore/cf_v2_storage.go::resolve()对route=="" && key==""同样直接回退。这对旧 CE 的现存 Repo 正确，但 SQL 并未验证Repo/RepoTrash/GarbageRepos里确实存在该 UUID；底层对象 API 使用一个合法但不存在的 repo UUID 时也可能被定位到原生目录。Hub 的storage_reconcile.inspect()已经校验原生 Repo 事实，C/Go 的合同不应放宽。优先做一个最小验证：原有 CE 库正常读写；不存在的 UUID/不完整路由拒绝，且不在默认目录生成新对象；原有 Trash/GC 路由可用。若要增强查询，尽量并入现有一次 lookup，不额外建映射表或缓存。该项是底层守护边界，非指已经证实存在用户越权。
servicememeai commentedon Oct 24, 2026
2026-10-24 补充离线兼容验收：Docker PR #40 增加无 CloudFile 服务、无 CloudFile SQL 的逐库定位/原生
seaf-fsck --export <dest> <repo_id>薄工具。按库根保留 Seafile 原生storage/commits|fs|blocks/<repo_id>，因此无需新文件引擎或离线写表。请保持原生 CE 对象格式和路径不变；默认
repo_key=repo_id，显式受信 key 仅作为外层目录名。即使 CloudFile 停机也能通过 UUID 在一层子目录中找到唯一物理根；重复 UUID/缺挂载拒绝猜测。此工具不承担全库备份、在线迁移、S3 或加密库解密，真实 CE14 原生导出仍需专项联验。servicememeai commentedon Oct 24, 2026
2026-10-24 V2 最小收敛已实现为 Server Draft PR #38，替代旧 #36（已关闭未合并）。保留现有 CloudFile V2 UUID 外层库目录 /
auto-local:<uuid>，由原生 RepoStorageId 独立决定位置。已有自定义 key V2 继续按旧 route 后缀读原目录；CE 无 route 仅在真实 Repo/Trash/GC 存在且缺失历史 V2 标记时走原生目录。用现有 cf_library_storage 的 UUID 标记堵住丢失 route 后的错误回退，不设新表/活跃状态机；Commit/Owner/历史 GC 均交 Seafile。实际 C + Go 定向验证 Actions #40091488630 通过，仍需完整 CE14 进程 RPC/GC/fsck 验收，保持 Draft。
opendev9 commentedon Oct 24, 2026
状态更新（2026-10-24 22:15 +08）：
auto-local/repo_key的 V2 UUID-only 方案已由 #38 合并进dev（验收门禁修复：server#39 / hub#81 / docker#43）。本机隔离 CE14 + MariaDB 门禁（当前 dev head 构建镜像，66/66）：
RepoStorageId=auto-local:<repo_uuid>+cf_library_storage最小安全标记，物理目录library-storage/<uuid>/storage/{commits,fs,blocks}/<uuid>；auto-local:<old_key>按原 route 原址解析、不迁移；保持 Open：东京 DEV 真实服务验收与固定 SHA/镜像 Digest 证据未完成。
opendev9 commentedon Oct 25, 2026
关闭说明：V2 自动本地每库路由已合并并验收
bf6e5db：新库默认RepoStorageId=auto-local:<repo_uuid>，物理目录为 UUID；历史自定义 key 按原 route 读原目录；失路由 fail-closed，不回落原生；93d312a：虚拟库建库窗口纳入 C/Go 存在判定，共享子目录不再必失败。真实 CE14 + MariaDB 联合验收 66/66（含 fresh V2、历史 custom-key、原生 CE、虚拟库、fsck/cold GC、CE→V2 切换）。稳定的业务
repo_key不作为物理路径入口（见 Hub #68）。后续多 Storage Class/S3 由 #35 单独跟踪。