[fs][v2] scope-wide requireLiteralLeadingDot config not working

[ayangweb]

The writeFile execution reported an error, I suspect that it is because the path is a path containing a . path, how can I fix this? I am using appDataDir path!

[FabianLars]

Can you also share your configured permissions?

[ayangweb]

{
  "fs:read-files",
  "fs:allow-write-file",
  "fs:allow-copy-file",
  "fs:allow-remove",
  {
    "identifier": "fs:scope",
    "allow": ["**/*"]
  },
}

[ayangweb]

It works fine in macos and windows! Only in linux it reports errors!

[FabianLars]

Yeah, if you only use that scope than the dot is indeed the issue. Either add explicit $APPDATA based scopes or change your existing scope to this

{
  "identifier": "fs:scope",
  "allow": ["**/*"],
  "requireLiteralLeadingDot": false
},

[ayangweb]

Hey👋, requireLiteralLeadingDot set to false also reports the same error!

iShot_2024-10-13_21.55.56.mp4

[FabianLars]

Hmm, that's weird. Just to double check, does ["$APPDATA/*"] work? Also, can you share the function call that's failing?

[ayangweb]

["$APPDATA/*"] also gives an error, also the final export path is chosen by the user, so I wrote ["**/*"].

iShot_2024-10-13_22.04.10.mp4

export const writeFile = (
	path: string,
	data: string,
	options?: WriteFileOptions,
) => {
	const encoder = new TextEncoder();
	const encodeData = encoder.encode(data);

	return tauriWriteFile(path, encodeData, options);
};

await writeFile(getBackupStorePath(), JSON.stringify(content));

[ayangweb]

On macOS and windows, it is normal

iShot_2024-10-13_22.06.40.mp4

[FabianLars]

also the final export path is chosen by the user, so I wrote ["**/*"].

If you use the dialog plugin for that then the scope would be dynamically extended btw, but yeah your solution works too of course.

On macOS and windows, it is normal

Yeah, that's just another argument for the dot being the issue.

I guess the scope-wide requireLiteralLeadingDot setting doesn't work right now then. Try adding this to tauri.conf.json then:

{
  "plugins": {
    "fs": {
      "requireLiteralLeadingDot": false
    }
  }
}

[ayangweb]

It's working fine, thanks! This error report should be a problem caused by other code!

iShot_2024-10-13_22.17.28.mp4

[ayangweb]

By the way, I looked at the source code for the stat method, and the size of the folder is also metadata.len(), so it doesn't get the correct size, is it designed this way on purpose? Or is it a bug?

plugins-workspace/plugins/fs/src/commands.rs

Line 1117 in 7e1c17a

size: metadata.len(),

[FabianLars]

well, it's at least not supposed to get the correct folder size because that only works by iterating over all files recursively which is just too slow for a simple stat function. I don't know whether it should still call len() or just return 0 but as long as it doesn't panic or anything i think it's fine as-is (isn't a folder 4kb or something on Linux?).

[ayangweb]

This is the problem I encountered with stat, it has nothing to do with the platform, it counts the folder size incorrectly on whichever platform it is on, the folder size needs to be implemented by a recursive function!