Reading `~/Documents` and the files in there.

[hybrid shoal]

I'm using Tauri v2, and I'm trying to list all the markdown documents in ~/Documents. I just can't get the permissions to work. No matter what I try, I get these errors:

Error: failed to read directory at path: /Users/krisjenkins/Documents with error: No such file or directory (os error 2)

Error: forbidden path: /Users/krisjenkins/Documents/The_King_Is_Dead.md

(Yes, that directory and file both exist. 😁)

Here's the current contents of src-tauri/capabilities/default.json:

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "description": "enables the default permissions",
  "windows": [
    "main"
  ],
  "permissions": [
    "core:default",
    "fs:allow-document-read",
    {
      "identifier": "fs:allow-read-dir",
      "allow": [
        {
          "path": "$DOCUMENT"
        }
      ]
    },
    {
      "identifier": "fs:allow-read-text-file",
      "allow": [
        {
          "path": "$DOCUMENT/*.md"
        }
      ]
    }
  ]
}

And here's the relevant JavaScript I'm calling:

const documentDirPath = await documentDir();
const entries = await readDir(documentDirPath);
const markdowns = entries.filter((entry) => entry.name.endsWith(".md"));
return markdowns;

I've tried many variations on this, but whatever I do I'm stuck on the same error messages. 😭

Can anyone help, please? 🙏

[rapid rover]

No such file or directory -> This is not a scope error. This one means the path is simply incorrect and the system can't find it.

The other one however is indeed a scope error, is that thrown on the readDir line or when you try to read the file?

[hybrid shoal]

Thanks Fabian, but how can that be? /Users/krisjenkins/Documents definitely exists. It's been there since the OS was installed. And the terminal has Full Disk Access permissions. Also, ls /Users/krisjenkins/Documents returns what I'd expect. 🤔

Ah, I missed out the JS for the second error. That's being thrown when I call:

import { documentDir } from "@tauri-apps/api/path";
import { readDir, readFile } from "@tauri-apps/plugin-fs";

...

const contents = await readFile(path);

FTR, output of tauri info:

[✔] Environment
    - OS: Mac OS 15.1.0 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (1980-01-01)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 22.2.0
    - yarn: 1.22.22
    - npm: 10.7.0

[-] Packages
    - tauri 🦀: 2.0.6
    - tauri-build 🦀: 2.0.2
    - wry 🦀: 0.46.3
    - tao 🦀: 0.30.5
    - @tauri-apps/api : 2.0.2
    - @tauri-apps/cli : 2.0.3

[-] Plugins
    - tauri-plugin-fs 🦀: 2.0.3
    - @tauri-apps/plugin-fs : 2.0.0
    - tauri-plugin-log 🦀: 2.0.1
    - @tauri-apps/plugin-log : 2.0.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1234/

[rapid rover]

hey sorry, for the delay, this thread slipped my mind a bit.
it seemed to work fine for me locally yesterday. Could you maybe try to reproduce it in a fresh create-tauri-app project and upload that?

Oh and one thing that may be worth to try is to extend the readdir scope ```json
{
"identifier": "fs:allow-read-dir",
"allow": [
{
"path": "$DOCUMENT"
},
{
"path": "$DOCUMENT/"
},
{
"path": "$DOCUMENT/**/"
}
]
},

[hybrid shoal]

Thanks @rapid rover. Sadly none of those things worked, so I cloned the plugin repo, dug in, and I believe I've found the problem. It's around here: https://github.com/tauri-apps/plugins-workspace/blob/v2/plugins/fs/src/commands.rs#L258

Turns out I have a broken symlink in the documents directory. Attempting to read that symlink's metadata throws an error, which https://github.com/tauri-apps/plugins-workspace/blob/v2/plugins/fs/src/commands.rs#L293-L294 then incorrectly reports as being a problem with the directory. It should report it as a problem with the file inside.

[rapid rover]

that sounds awfully familiar, i thought we fixed that

would you mind opening a github issue for this? it really shouldn't make the whole readfile call fail imo and i can't find an existing issue for this