[Feature Request] 将 HiSH 应用的 Downloads 文件夹挂载为共享文件夹

[HandwerSTD]

如题，现有的共享文件夹需要使用 Picker 一个个复制文件到沙箱内，很不方便，而且对文件管理不可见

可以考虑利用起来应用的专属下载文件夹，这个文件夹可以在文件管理器里访问，并且应用对其内部文件有完整的权限，挂载为共享文件夹也能实现HarmonyOS 宿主机和客户机直接互通的效果

获取该文件夹地址的代码：

  const documentViewPicker = new picker.DocumentViewPicker()
  let documentSaveResult = await documentViewPicker.save({ pickerMode: picker.DocumentPickerMode.DOWNLOAD })
  return new fileUri.FileUri(documentSaveResult[0]).path + '/'

[hackeris]

这个目录开放的权限不完整，例如无法删除文件，不足以支持共享文件夹相关的操作

[HandwerSTD]

这个目录开放的权限不完整，例如无法删除文件，不足以支持共享文件夹相关的操作

奇怪，我刚刚询问了几个开发者，他们说是可以的，并且仔细想想的话，浏览器也应该得有删除已下载文件的权限才对

[hackeris]

我实测碰到的问题是“模拟器”（里面用的应该是unlink调用）和fs.unlinkSync都删不掉文件，会提示没有权限

[HandwerSTD]

我写了个简单的示例，在 HarmonyOS 6.0.0.110 真机上实测能跑，你可以看看

      Button('Write file')
        .onClick(async () => {
          const documentViewPicker = new picker.DocumentViewPicker()
          let documentSaveResult = await documentViewPicker.save({ pickerMode: picker.DocumentPickerMode.DOWNLOAD })
          const downloadPath = new fileUri.FileUri(documentSaveResult[0]).path + '/'
          const file = fileIo.openSync(downloadPath + "test.txt", fileIo.OpenMode.CREATE | fileIo.OpenMode.WRITE_ONLY);
          fileIo.writeSync(file.fd, 'Heello Download dir!');
          fileIo.closeSync(file);
          promptAction.openToast({
            message: "write completed"
          })
        })
      Button('Delete file')
        .onClick(async () => {
          try {
            const documentViewPicker = new picker.DocumentViewPicker()
            let documentSaveResult = await documentViewPicker.save({ pickerMode: picker.DocumentPickerMode.DOWNLOAD })
            const downloadPath = new fileUri.FileUri(documentSaveResult[0]).path + '/'
            // const file = fileIo.openSync(downloadPath + "test.txt", fileIo.OpenMode.CREATE | fileIo.OpenMode.WRITE_ONLY);
            fileIo.unlinkSync(downloadPath + "test.txt")
            // fileIo.closeSync(file);
            promptAction.openToast({
              message: "delete completed"
            })
          } catch(e) {
            promptAction.openToast({
              message: 'delete err: ' + e.message + e.code
            })
          }
        })

[hackeris]

共享文件夹底层并不是通过 fileIo 访问文件的，猜测是 fileIo 内部还做了一些其它与权限控制有关的操作。
这是我实测用的分支：shared-downloads

目前的情况是：

• fileIo：真机可以删除文件，模拟设备不行
• 模拟器内：创建文件、创建文件夹、删除文件 都不行

[HandwerSTD]

尝试了一下 debug 模式跑到真机上，情况似乎更诡异一些

首先，真机上，Guest 对 Downloads 里文件树的任何修改操作都会导致 Guest 直接崩溃，包括但不限于 mkdir, touch, chmod, rm, echo > newfile，并且 HiSH 不报 cppcrash，Log 窗格只有孤零零的一条：

C03F00/MUSL                     app.hackeris.hish     W     CallbackFunction return ASSERT_ABORT:

但是，有意思的是，这些操作实际上已经成功完成了，它们真的可以创建、删除文件和文件夹，并且这些修改也能在文件管理器中看到；chmod 不生效，并且所有的文件都会被 HarmonyOS 强制修改为 rw-rw----，属于 group 1006，owner 20001006

此外，在不修改文件树的情况下打开并写入已存在的文件是正常的，可以正常使用 vi 编辑并保存里面的内容

[HandwerSTD]

我的想法是

• 可以先想办法抓抓 Log 看看为什么闪退，然后把除了 chmod chown 的文件操作都修了，这样 root 用户可以正常使用共享下载文件夹
• 保留原先的沙箱共享文件夹，因为要考虑到 service 和 docker 用户不会直接用 root 执行，他们得依赖 chmod o+r；这样的话可以把下载文件夹新挂载到 /mnt/shareDown 里面，也保留一些前向兼容性
• 如果实在修不了的话，可以考虑把 Downloads 作为一个文件中转站，用户先向 Downloads 放文件，然后由 HiSH 批量拷贝到沙箱共享文件夹，实现一个更方便的批量导入操作

[HandwerSTD]

刚刚又上机试了一下，rm 突然又没问题了，然后在 touch 的时候 abort 了：

* thread #176, name = 'p.hackeris.hish', stop reason = breakpoint 6.1
  * frame #0: 0x0000005b2e76a8c0 ld-musl-aarch64.so.1`abort
    frame #1: 0x0000005b2e76ab10 ld-musl-aarch64.so.1`__assert_fail + 312
    frame #2: 0x0000005cef38c30c libqemu-system-aarch64.so`local_set_mapped_file_attrat + 1064
    frame #3: 0x0000005cef38aee4 libqemu-system-aarch64.so`local_open2 + 212
    frame #4: 0x0000005cef39896c libqemu-system-aarch64.so`v9fs_co_open2 + 240
    frame #5: 0x0000005cef38ff9c libqemu-system-aarch64.so`v9fs_lcreate + 444
    frame #6: 0x0000005cefce59f8 libqemu-system-aarch64.so`coroutine_bootstrap + 44
    frame #7: 0x0000005cefce587c libqemu-system-aarch64.so`coroutine_trampoline + 140
    frame #8: 0x0000005b2eb00cb4 [vdso]`___lldb_unnamed_symbol14 + 44
    frame #9: 0x0000005b2eb00468 [vdso]`_except_tag_nopf_end + 16

那就是定位到文件 "../hw/9pfs/9p-local.c:310"，函数 local_set_mapped_file_attrat 的某一句，assert(ret == 0)，这个地方 abort 了，初步推测了一下应该是调用 fchmod 死掉了？

upd：ret = -1

[hackeris]

看样子把这个干掉就可以了 hw/9pfs/9p-local.c:L310

[hackeris]

在这里支持了，合到master里了