Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ayangweb opened this issue Oct 13, 2024 · 13 comments
Open

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

ayangweb opened this issue Oct 13, 2024 · 13 comments
Labels
bug Something isn't working plugin: fs Includes former "fs-extra" and "fs-watch" plugins

Comments

@ayangweb
Copy link

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!

image
@FabianLars
Copy link
Member

Can you also share your configured permissions?

@FabianLars FabianLars added question Further information is requested plugin: fs Includes former "fs-extra" and "fs-watch" plugins labels Oct 13, 2024
@ayangweb
Copy link
Author

ayangweb commented Oct 13, 2024

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

@ayangweb
Copy link
Author

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

@FabianLars
Copy link
Member

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
},

@FabianLars FabianLars closed this as not planned Won't fix, can't repro, duplicate, stale Oct 13, 2024
@ayangweb
Copy link
Author

ayangweb commented Oct 13, 2024

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

iShot_2024-10-13_21.55.56.mp4

@FabianLars
Copy link
Member

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

@FabianLars FabianLars reopened this Oct 13, 2024
@ayangweb
Copy link
Author

ayangweb commented Oct 13, 2024

["$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
Copy link
Author

ayangweb commented Oct 13, 2024

On macOS and windows, it is normal

iShot_2024-10-13_22.06.40.mp4

@FabianLars
Copy link
Member

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
    }
  }
}

@FabianLars FabianLars added bug Something isn't working and removed question Further information is requested labels Oct 13, 2024
@ayangweb
Copy link
Author

ayangweb commented Oct 13, 2024

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

iShot_2024-10-13_22.17.28.mp4

@FabianLars FabianLars changed the title [fs][v2] Error executing writeFile [fs][v2] scope-wide requireLiteralLeadingDot config not working Oct 13, 2024
@ayangweb
Copy link
Author

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?

size: metadata.len(),

@FabianLars
Copy link
Member

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
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working plugin: fs Includes former "fs-extra" and "fs-watch" plugins
Projects
None yet
Development

No branches or pull requests

2 participants