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

vfs: error when opening files from constfs filesystem #93

Closed
maikerlab opened this issue Apr 26, 2024 · 2 comments · Fixed by #107
Closed

vfs: error when opening files from constfs filesystem #93

maikerlab opened this issue Apr 26, 2024 · 2 comments · Fixed by #107

Comments

@maikerlab
Copy link

maikerlab commented Apr 26, 2024

In my RIOT application I initialize the constfs file system and some private data in a c-file, exactly like in the filesystem example (with vfs_mount).
I can also open and read the contents inside the file (e. g. with fopen("/const/dac", "r") and open("/const/dac", O_RDONLY))
Reading from shell is also possible (e.g. with vfs r /const/dac 15 0)

In my Rust code, I first call the external C-Function, where vfs_mount gets called.
When iterating over all mount points with vfs::Mount::all() and files inside /const, everything looks as expected and the desired files exist.
But when trying to open a file (e.g. with vfs::File::open("/const/dac"), I get an error (-2 ENOENT 2 No such file or directory)

I could reproduce this error on native and nucleo-f429zi board

@maikerlab maikerlab changed the title vfs: failed t cannot open files from constfs filesystem vfs: error when opening files from constfs filesystem Apr 26, 2024
@chrysn
Copy link
Member

chrysn commented Aug 20, 2024

Just for reference (not sure when I get around to fixing this), this was known at https://gitlab.com/etonomy/riot-wrappers/-/issues/8 (but only tracked in this tracker through #26).

@chrysn chrysn added the wait-for-breaking-0.9 Change that is held for the 0.9 release, for it is a breaking change label Aug 20, 2024
@chrysn
Copy link
Member

chrysn commented Aug 21, 2024

I stand corrected: This is a different bug than the old issue 8.

Investigating…

chrysn added a commit that referenced this issue Aug 21, 2024
This fixes a severe bug where file names were passed to the C API that
expects nul-termination.

Closes: #93
@chrysn chrysn removed the wait-for-breaking-0.9 Change that is held for the 0.9 release, for it is a breaking change label Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants