[bug] use api fs.readTextFile case error

[wcly]

Describe the bug

trigger error when using api fs.readTextFile in production mode.

Reproduction

1. set tauri.conf.json

 "tauri": {
    "allowlist": {
      "all": true,
      "fs": {
        "scope": ["$RESOURCE/*"]
      }
  }
}

2. use api

import {
  readTextFile,
} from "@tauri-apps/api/fs";

async fucntion fun(){
 const contents = await readTextFile(localConfigPath);
}

3. build app

pnpm tauri build --debug

4. install app
5. run app

Expected behavior

readTextFile success.

Platform and versions

Environment
  › OS: Mac OS 12.5.1 X64
  › Node.js: 16.13.2
  › npm: 8.1.2
  › pnpm: 7.10.0
  › yarn: 1.22.18
  › rustup: 1.25.1
  › rustc: 1.63.0
  › cargo: 1.63.0
  › Rust toolchain: stable-x86_64-apple-darwin 

Packages
  › @tauri-apps/cli [NPM]: 1.0.5
  › @tauri-apps/api [NPM]: 1.0.2
  › tauri [RUST]: 1.0.5,
  › tauri-build [RUST]: 1.0.4,
  › tao [RUST]: 0.12.2,
  › wry [RUST]: 0.19.0,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../dist
  › devPath: http://localhost:1420/

App directory structure
  ├─ dist
  ├─ node_modules
  ├─ public
  ├─ src-tauri
  ├─ .git
  ├─ .vscode
  └─ src

Stack trace

No response

Additional context

It only throw error in production mode, work on dev mod

[Moon1102]

Same issue under MacOS 11.4, cannot access $RESOURCE/* in production mode. As a comparison, I tried scope like"scope": ["$APP/*"] which mentioned in the example (https://github.com/tauri-apps/tauri/issues/3573) is accessible in production environment. Besides, I also found the scope like "scope": ["$DOCUMENT/*"] is work too, just need user authorization(it will pop a authorization window).

here is my js code:

const fun = async () => {
    //quoted from #3573
    await readDir('resources', { dir: Dir.Resource }).then(console.log).catch(console.error)

    const contents = await readTextFile('a.txt', { dir: Dir.App });
    console.log('contents: ', contents);
}
fun();

and part of tauri.config.json like:

 "fs": {
        "all": true,
        "scope": [
          "$RESOURCE/*",
          "$APP/*"
        ]
      }

 "resources": [
      "resources"
 ],

[FabianLars]

@Moon1102 I think readDir needs the folder itself on the scope too, like this

    "fs": {
        "all": true,
        "scope": [
          "$RESOURCE",
          "$RESOURCE/*",
          "$APP/*"
        ]
      }

i don't know what's wrong with OP's issue tho :(

[Moon1102]

@FabianLars emmm

dev mode shows: Whether "scope": ["$RESOURCE"] is added or not will not affect access ( I think maybe"$RESOURCE/*"'s scope includes its own folder )

but production mode shows: Neither the folder nor the files under it can be accessed, even with scope "scope": ["$RESOURCE"] was added.

[FabianLars]

I think maybe"$RESOURCE/*"'s scope includes its own folder

pretty sure it doesn't, but the globe scope stuff is a little weird at times so it's good to check twice.

[Moon1102]

I think maybe"$RESOURCE/*"'s scope includes its own folder

pretty sure it doesn't, but the globe scope stuff is a little weird at times so it's good to check twice.

Thanks for your pointers. It seems that $RESOURCE/* cannot be accessed in production now ( in my test ). I will try all the global scopes in a while :)

[Moon1102]

@FabianLars

Excuse me. I change my fs section of tauri.config.json to:

 "fs": {
        "all": true,
        "scope": [
          "$AUDIO", "$AUDIO/*",
          "$CACHE", "$CACHE/*",
          "$CONFIG", "$CONFIG/*",
          "$DATA", "$DATA/*",
          "$LOCALDATA", "$LOCALDATA/*",
          "$DESKTOP", "$DESKTOP/*",
          "$DOCUMENT", "$DOCUMENT/*",
          "$DOWNLOAD", "$DOWNLOAD/*",
          "$EXE", "$EXE/*",
          "$FONT", "$FONT/*",
          "$HOME", "$HOME/*",
          "$PICTURE", "$PICTURE/*",
          "$PUBLIC", "$PUBLIC/*",
          "$RUNTIME", "$RUNTIME/*",
          "$TEMPLATE", "$TEMPLATE/*",
          "$VIDEO", "$VIDEO/*",
          "$RESOURCE", "$RESOURCE/*",
          "$APP", "$APP/*",
          "$LOG", "$LOG/*",
          "$TEMP", "$TEMP/*"
        ]
      }

after traversed all variables in fs.security:

dev mode result:

production mode result:

As the figure shown, the variables $APP $DOCUMENT $DESKTOP can be accessed in both modes; $EXE $RUNTIME $TEMP,to be honest, I don't really care about them, it's okay not to discuss them; $RESOURCE, it still looks like it only works fine in dev mode :(

[FabianLars]

$EXE $RUNTIME $TEMP,to be honest, I don't really care about them

Not all paths exist on all 3 platforms, that's where the unable to determine base dir path errors come from.

Anyway, i can't help here because i don't have access to macos, so we need to wait for team members that do have access, but they are pretty busy right now.

[Moon1102]

$EXE $RUNTIME $TEMP,to be honest, I don't really care about them

Not all paths exist on all 3 platforms, that's where the unable to determine base dir path errors come from.

Anyway, i can't help here because i don't have access to macos, so we need to wait for team members that do have access, but they are pretty busy right now.

I understand. Anyway, thanks for your help