readdir() skips files if the directory is modified, behaviour is not POSIX-compliant.

[Vincent-Dalstra]

This causes problems when deleting files in a directory that is currently open.

A good example is the following code: it is supposed to delete all the files in a directory, but it will instead skip every second file.

#include <sys/unistd.h>
#include <sys/dirent.h>

int delete_all_files(const char* dirpath)
{
    DIR* dir = opendir(dirpath);
    if (dir == NULL) return -1;

    struct dirent* entry;
    while ((entry = readdir(dir)) != NULL) {
        if (entry->d_type != DT_REG) continue;
        char path[PATH_MAX];
        strcpy(path, dirpath);
        strcat(path, "/");
        strcat(path, entry->d_name);
        unlink(path);
    }
    closedir(dir);
    return 0;
}

Following POSIX specifications, the function should work:

If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir_r() returns an entry for that file is unspecified.

The source of the problem is the way directory handles currently work; they record a pointer to the directory object (ramfs_fs_t), and an index (loc) indicating position. However, when a file is deleted, it causes all entries after it to be moved back a space. This MAY cause an entry to get skipped.

[Vincent-Dalstra]

A fix for this issue can be found in #6.

[jkent]

Awesome. I'll work on this today. You've inspired me to look into Unity with IDF.

[Vincent-Dalstra]

Unity is very handy, can recommend it. I had wanted to use TDD for a while, and I was finally able to do it. It makes it much easier to write reliable 'building blocks', such as this code.

Be warned, if you're using the espressif-ide (eclipse): the linter/indexer is probably going to be a pain. For whatever reason, it will not properly recognize the 'test' components as being part of the build, resulting in (1) lots of linter errors and (2) 'Find definition' and 'Find references' won't work properly. It will compile perfectly fine, though.

I figured out a way to fix it by structuring the project/test apps differently, then using if() statements in the CMakeLists.txt. It's a little bit cursed though, so hopefully you won't need it.

[Vincent-Dalstra]

I made a dedicated test project for running the unit tests: https://github.com/Vincent-Dalstra/ramfs_test_app
It is essentially just the project I was developing, with everything except ramfs removed. It includes ramfs as a submodule, allowing development from within the test repo.

[jkent]

Thanks Vincent. I'll look at it tomorrow! I don't use the eclipse solution, but instead use vscode with the ESP-IDF extension. You might have noticed my tests I wrote in C that run under the meson build system. They of course don't cover the VFS code, but they were a good solution to keep the rbtree and vector based implementations in sync with changes, and you don't have to wait on the build process or flashing process to run your tests since they run on the host. I'm curious if the Unity tests can run within QEMU.

Kind regards,
Jeff