dsh-mobile-plugin 0.3.1 → 0.4.1

package/lib/mobile/uploads.js

@@ -3,26 +3,17 @@
 /**
  * 移动端文件分片上传：把手机分享进来的文件落到宿主机固定收件目录。
  *
- * 四步：begin（登记文件名，拿 uploadId 与片大小）→ chunk（按 index 顺序追加）→
- * finish（落盘成 `<收件根>/<日期>/<文件名>`，重名自动加后缀）→ abort（放弃）。
+ * 四步：begin（登记文件名，拿 uploadId 与片大小）→ chunk（按 index 顺序追加）→ finish
+ * （落盘成 `<收件根>/<日期>/<文件名>`，重名自动加后缀）→ abort（放弃）。
  *
- * 为什么分片，而不是一次 POST 传完：
- *   - 一次传完会把「能传多大的文件」变成一条运维配置 —— 中转的
- *     `MAX_BODY_BYTES`（dsh-mobile-server/lib/config.js）默认 50MB，插件自己的
- *     readJsonBody 默认只有 256KB。分片后单请求最大只有 2MB，与这些上限无关。
- *   - 手机侧网络不稳，分片能只重传坏掉的那一片，而不是整个文件。
+ * 分片而不是一次传完：单请求因此与中转的 `MAX_BODY_BYTES`、readJsonBody 的 256KB 上限无关，
+ * 手机网络不稳时也能只重传坏掉的那一片。片内容走 base64 而不是原始字节：App 侧没有发二进制
+ * body 的先例，图片通道本来就以 base64 走 JSON；代价是 33% 膨胀，仍远低于各层上限。
  *
- * 为什么片内容走 base64 而不是原始字节：隧道协议本身支持原始字节
- * （lib/relay/protocol.js 的 httpBody 帧），但 App 侧没有任何「发二进制 body」的
- * 先例，RN 的 fetch 对 ArrayBuffer body 的支持也随版本变；图片通道本来就以 base64
- * 走 JSON，这里沿用同一条确定能用的路。代价是 33% 膨胀（单片 2MB → 约 2.73MB），
- * 仍远低于任何一层上限。
+ * 顺序与幂等：chunk 只接受下一片，重复送达同一片按重传处理，跳号直接 409。
  *
- * 顺序与幂等：chunk 只接受「下一片」，重复送达同一片按重传处理（回当前 received，
- * 不再追加），跳号直接 409 —— 客户端因此不需要在重试前先问进度。
- *
- * 落盘根目录固定 `~/.dsh/mobile-inbox`（收件专目录，与工作区解耦，工作区被删也不
- * 影响已收到的文件）。`DSH_MOBILE_INBOX` 可覆盖，只给测试用。
+ * 收件根固定 `~/.dsh/mobile-inbox`，与工作区解耦（工作区被删不影响已收到的文件）；
+ * `DSH_MOBILE_INBOX` 可覆盖，只给测试用。
  */
 
 const fsp = require('node:fs/promises');

package/lib/mobile/workspaces.js

@@ -3,15 +3,12 @@
 /**
  * dsh-mobile 工作区/目录浏览：透传宿主 apiProxy 的目录浏览与工作区采纳 RPC。
  *
- * 移动端是**远程遥控器**——它不能像桌面端那样弹被控端的原生目录对话框。
+ * 移动端是远程遥控器，不能像桌面端那样弹被控端的原生目录对话框。
  *
- * 这里曾经写着一个**错的**前提：以为 directory-picker-auto 会在「宿主绑定局域网（非
- * 127.0.0.1）」时自动启用 `browse` 能力，于是 `apiProxy.host.listDirectory` /
- * `host.createDirectory` 在任何被控端都可用。实际不是：auto 只在「web 服务绑到非回环」
- * 或「平台不是 darwin/win32」时挂 browse，而**桌面 profile 宿主**（手机经 sidecar/中转
- * 连上的那种）两者都不满足，于是恒解析成 native —— 手机端一个条目都列不出来，只能登记
- * 一个恰好已存在的目录。现在这两个动词在宿主不服务 browse 时由插件自带实现兜底，见
- * lib/mobile/directory-browse.js。本模块仍只做与 sessions.js 相同的透传包装。
+ * directory-picker-auto 只在「web 服务绑到非回环」或「平台不是 darwin/win32」时挂 browse，
+ * 桌面 profile 宿主两者都不满足、恒解析成 native。所以宿主不服务 browse 时，两个目录动词由
+ * 插件自带实现兜底（见 lib/mobile/directory-browse.js）；本模块只做与 sessions.js 相同的
+ * 透传包装。
  */
 
 const { sendJson, readJsonBody } = require('../shared/http-util');
@@ -27,6 +24,7 @@ const { withIdempotency, requestIdOf } = require('./idempotency.js');
 const { canonicalDeviceKey } = require('./session-cache.js');
 const { unwrap } = require('./envelope.js');
 const { describeProjectGit } = require('./git-repos.js');
+const { listRoots } = require('./drive-roots.js');
 
 /** 调宿主 apiProxy.host.*（directory-picker 的 browse 能力）。 */
 function callHost(ctx, method, payload) {
@@ -167,6 +165,19 @@ async function handleListDirectory(ctx, req, res) {
   sendJson(res, 200, { ok: true, listing: value });
 }
 
+/**
+ * GET /api/mobile/v1/directory/roots（token）
+ * 「添加工作区」的盘符层：宿主 browse 后端只列某一层目录的内容、从不枚举盘符，而手机端的
+ * 目录浏览器一打开就落在被控端主目录 —— Windows 上它永远在 C 盘，别的盘没有任何入口。
+ * Windows 回真实存在的盘符，其余平台回文件系统根；只有一项时 App 不显示这一层。
+ *
+ * 不走宿主：host.listDirectory 只认路径、给不出一份根清单，而枚举本身与目录选择器的部署
+ * 形态无关（browse / native 两种宿主下答案一样）。
+ */
+async function handleDirectoryRoots(_ctx, _req, res) {
+  sendJson(res, 200, { ok: true, roots: await listRoots() });
+}
+
 /**
  * POST /api/mobile/v1/directory/create（token）{ path, name }
  * 透传宿主 host.createDirectory：在被控端 `path` 下新建名为 `name` 的文件夹。
@@ -339,6 +350,7 @@ module.exports = {
   handleMoveWorkspace,
   handleWorkspaces,
   handleListDirectory,
+  handleDirectoryRoots,
   handleCreateDirectory,
   handleCreateWorkspace,
   handleRenameWorkspace,