-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
POSIX stat function returns filesystem statistics, not file statistics #58911
Comments
@plinnie - are you able to make a PR? Looks like it might be a 1-line fix. Feel free to ping me if you require any assistance. |
Yes, but at a second glance it is a bit more involved. I need to gather from fs_stat and fs_statvfs. Additionally I will add unit tests. Also some corner cases need to be defined in more detail (e.g.. |
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes #58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Fixes zephyrproject-rtos#58911. Previously the stat command returned information on the filesystem, but not the file itself. Because block size is still set this function is backwards compatible with the previous faulty behavior. Signed-off-by: Vincent van Beveren <v.van.beveren@nikhef.nl>
Please see Discord discussion https://discord.com/channels/720317445772017664/883450954878439445/1115355325055381625 .
Describe the bug
When using the POSIX function stat the returned statistics are not those of the file passed as an argument, but that from the filesystem the file is located on.
The bug present in the current master, and appears in the POSIX filesystem layer of Zephyr.
To Reproduce
Write application which uses stat function with CONFIG_POSIX_FS=y .
Expected behavior
To get actual information of the file.
Impact
File size and attribute retrieval will not return the expected result. For example our application using mongoose did not function properly, as mongoose uses the stat function to determine the file size when using the default filesystem API.
Environment (please complete the following information):
Additional context
CONFIG_POSIX_FS=y
See:
zephyr/lib/posix/fs.c
Line 359 in be1e7e8
I would expect it to call fs_stat and not fs_statvfs as it does now.
The text was updated successfully, but these errors were encountered: