Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 21 additions & 1 deletion components/dfs/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -152,9 +152,29 @@ endif
depends on RT_DFS_ELM_REENTRANT

config RT_DFS_ELM_USE_EXFAT
bool "Enable RT_DFS_ELM_USE_EXFAT"
bool "Enable exFAT filesystem support"
default n
depends on RT_DFS_ELM_USE_LFN >= 1
help
exFAT (Extended File Allocation Table) is a file system
designed for large-capacity storage devices.

Key features and recommendations:
- Target scenarios: Primarily used for storage media requiring
support for very large files (>4GB) or large partitions
(>32GB), such as high-capacity SD cards or USB drives.

- Resource cost: Enabling exFAT support will significantly
increase the code size (ROM footprint) of the file system.

- Recommendation:
For small-capacity storage devices (e.g., SPI Flash or
eMMC under 32GB), the standard FAT16 or FAT32 file
systems are perfectly adequate. It is strongly recommended
to keep this option disabled unless you absolutely need to
handle large-capacity storage, in order to conserve
valuable code space.

endmenu
endif

Expand Down
6 changes: 2 additions & 4 deletions components/dfs/dfs_v1/filesystems/elmfat/dfs_elm.c
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
* 2017-02-13 Hichard Update Fatfs version to 0.12b, support exFAT.
* 2017-04-11 Bernard fix the st_blksize issue.
* 2017-05-26 Urey fix f_mount error when mount more fats
* 2025-10-29 wdfk-prog Fixed a memory leak in dfs_elm_close
*/

#include <rtthread.h>
Expand Down Expand Up @@ -468,10 +469,7 @@ int dfs_elm_close(struct dfs_file *file)
FRESULT result;

RT_ASSERT(file->vnode->ref_count > 0);
if (file->vnode->ref_count > 1)
{
return 0;
}
RT_ASSERT(file->data != RT_NULL);
Comment on lines 471 to +472
Copy link

Copilot AI Oct 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bug/错误: The assertion file->data != RT_NULL should use file->data != NULL for consistency with the rest of the codebase. RT-Thread code typically uses RT_NULL for RT-Thread API pointer parameters but NULL for standard C pointer checks. However, more critically, this assertion may be too strict - when ref_count > 1, the file->data could legitimately be NULL since the dfs_elm_open function only allocates file->data when ref_count == 1 (line 345-353 shows early return when ref_count > 1, and data allocation happens later). This assertion could cause crashes in valid multi-reference scenarios.

English: The assertion on line 472 is problematic. When vnode->ref_count > 1, multiple file descriptors share the same vnode but may have different file->data values. The dfs_elm_open function only allocates memory for file->data when opening a new file (ref_count == 1), but returns early when ref_count > 1. This means that for duplicate file descriptors, file->data might not be allocated, making this assertion incorrect and potentially causing crashes.

中文:第472行的断言存在问题。当 vnode->ref_count > 1 时,多个文件描述符共享同一个vnode但可能有不同的 file->data 值。dfs_elm_open 函数仅在打开新文件时(ref_count == 1)为 file->data 分配内存,但在 ref_count > 1 时会提前返回。这意味着对于重复的文件描述符,file->data 可能未被分配,使得此断言不正确并可能导致崩溃。

Copilot uses AI. Check for mistakes.
result = FR_OK;
if (file->vnode->type == FT_DIRECTORY)
{
Expand Down