[DFS_V1]修复 dfs_file_stat 一个 FATFS 根目录会失败的问题

[WKJay]

拉取/合并请求描述：(PR description)

[

为什么提交这份PR (why to submit this PR)

在使用 ART-PI BSP 时发现启用 sdcard 文件系统后在终端输入 ls 会有如下显示：

sdcard 目录被识别成了 BAD file。实际上此时 cd sdcard 是正常可以进入的。并且内部的文件都能够正常查看。而且这个问题似乎是最近才出现的。

经排查发现这个问题是由这个PR引入的：
#7887

该PR中删除了 dfs_file.c 中对当前是否是根目录的判断，导致无论是否是根目录都会进入 fs->ops->stat 的调用，进而调用到 f_stat，然而在目前版本的 FATFS 的 f_stat 在发现当前是根目录时会返回一个 FR_INVALID_NAME 的错误导致最终目录信息获取失败。

FRESULT f_stat (
    const TCHAR* path,	/* Pointer to the file path */
    FILINFO* fno		/* Pointer to file information to return */
)
{
    FRESULT res;
    DIR dj;
    DEF_NAMBUF


    /* Get logical drive */
    res = mount_volume(&path, &dj.obj.fs, 0);
    if (res == FR_OK) {
        INIT_NAMBUF(dj.obj.fs);
        res = follow_path(&dj, path);	/* Follow the file path */
        if (res == FR_OK) {				/* Follow completed */
------->    if (dj.fn[NSFLAG] & NS_NONAME) {	/* It is origin directory */
                res = FR_INVALID_NAME;
            } else {							/* Found an object */
                if (fno) get_fileinfo(&dj, fno);
            }
        }
        FREE_NAMBUF();
    }

    LEAVE_FF(dj.obj.fs, res);
}

目前不是很清楚 #7887 在这方面的修改是否有必要的，如果有必要的话可能需要讨论一下上述问题的正确解决方案

你的解决方案是什么 (what is your solution)

恢复之前 dfs_file_stat 中对根目录的单独处理逻辑

在什么测试环境下测试通过 (what is the test environment)

ART-PI

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 代码是高质量的 Code in this PR is of high quality
• 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification

[geniusgogo]

去/dev目录下ls看看呢？

[WKJay]

去/dev目录下ls看看呢？

/dev 下 ls 没有问题：

看了一下 devfs.c 下的 dfs_device_fs_stat 是有根目录判断的

int dfs_device_fs_stat(struct dfs_filesystem *fs, const char *path, struct stat *st)
{
    /* stat root directory */
    if ((path[0] == '/') && (path[1] == '\0'))
    {
        st->st_dev = 0;

        st->st_mode = S_IFREG | S_IRUSR | S_IRGRP | S_IROTH |
                      S_IWUSR | S_IWGRP | S_IWOTH;
        st->st_mode &= ~S_IFREG;
        st->st_mode |= S_IFDIR | S_IXUSR | S_IXGRP | S_IXOTH;

        st->st_size  = 0;
        st->st_mtime = 0;

        return RT_EOK;
    }
    else
    {
        rt_device_t dev_id;

        dev_id = rt_device_find(&path[1]);
        if (dev_id != RT_NULL)
        {
            st->st_dev = 0;

            st->st_mode = S_IRUSR | S_IRGRP | S_IROTH |
                          S_IWUSR | S_IWGRP | S_IWOTH;

            if (dev_id->type == RT_Device_Class_Char)
                st->st_mode |= S_IFCHR;
            else if (dev_id->type == RT_Device_Class_Block)
                st->st_mode |= S_IFBLK;
            else if (dev_id->type == RT_Device_Class_Pipe)
                st->st_mode |= S_IFIFO;
            else if (dev_id->type == RT_Device_Class_Bus)
                st->st_mode |= S_IFDIR;
            else
                st->st_mode |= S_IFREG;

            st->st_size  = 0;
            st->st_mtime = 0;

            return RT_EOK;
        }
    }

    return -ENOENT;
}

[XYZ-20240101]

这个问题对比了一下 dfs v2 那边是修改了 f_stat 函数中的代码，这边建议按照 v2 这边一样做修改来解决这个问题

[WKJay]

这个问题对比了一下 dfs v2 那边是修改了 f_stat 函数中的代码，这边建议按照 v2 这边一样做修改来解决这个问题

@yangfasheng @geniusgogo @BernardXiong 这样改是可以的，但是我看最新的 fatfs 源码这部分并没有做改变，也就是说这样改以后 RTT 的 elmfat 就和 fatfs 官方不同步了，而且如果后面有其他文件系统支持的话有几率都要进行这部分的修改。如果没问题的话我就这么改。

[BernardXiong]

这个问题对比了一下 dfs v2 那边是修改了 f_stat 函数中的代码，这边建议按照 v2 这边一样做修改来解决这个问题

@yangfasheng @geniusgogo @BernardXiong 这样改是可以的，但是我看最新的 fatfs 源码这部分并没有做改变，也就是说这样改以后 RTT 的 elmfat 就和 fatfs 官方不同步了，而且如果后面有其他文件系统支持的话有几率都要进行这部分的修改。如果没问题的话我就这么改。

先这样修改吧，未来还确实不确定能否和elm fatfs那边保持同步

[WKJay]

先这样修改吧，未来还确实不确定能否和elm fatfs那边保持同步

@BernardXiong
已完成修改

[mysterywolf]

这处入侵式修改得用小本本记下来