How to clear littleFS?

Firmware
,
1

Having not used littleFS before, and reading the documentation, I did not find a command to “erase the harddrive” from user firmware for the littleFS POSIX filesystem.

How can this be achieved quickly without going into detail with what is actually on the file system?

2

A quick (and very dirty and recursive and heap-using) snippet of code to list entire contents of the filesystem…

#include <dirent.h>
#include <fcntl.h>

void _ls(String &path, int level, DIR *dir)
{
    struct dirent *entry;

    String indent;

    indent.reserve(level);
    for(int i=0; i < level; i++)
    {
        indent += '\t';
    }

    while((entry = readdir(dir)) != NULL)
    {
        String new_path;
        struct stat st;
        
        if(path.length() && path[path.length()-1] == '/')
        {
            new_path = String::format("%s%s", path.c_str(), entry->d_name);
        }
        else
        {
            new_path = String::format("%s/%s", path.c_str(), entry->d_name);
        }

        if(entry->d_type == DT_REG && !stat(new_path, &st))
        {
            Log.info("%s%s %lu bytes", indent.c_str(), entry->d_name, st.st_size);
        }
        else
        {
            Log.info("%s%s", indent.c_str(), entry->d_name);
        }

        if(entry->d_type == DT_DIR && strcmp(entry->d_name, ".") && strcmp(entry->d_name, ".."))
        {
            DIR *new_dir = opendir(new_path);
            if(new_dir)
            {
                _ls(new_path, level + 1, new_dir);
                closedir(new_dir);
            }
        }
    }
}

void ls(String path)
{
    DIR *dir;
    dir = opendir(path);
    if(dir)
    {
        _ls(path, 0, dir);
        closedir(dir);
    }
}

Run this on your device as ls("/") and you might find something like the following (for an empty filesystem).

0000001189 [app] INFO: .
0000001191 [app] INFO: ..
0000001194 [app] INFO: sys
0000001197 [app] INFO: 	.
0000001197 [app] INFO: 	..
0000001199 [app] INFO: 	dct.bin 8391 bytes
0000001200 [app] INFO: 	openthread.dat 16 bytes
0000001202 [app] INFO: 	cellular_config.bin 0 bytes
0000001204 [app] INFO: 	eeprom.bin 4096 bytes
0000001205 [app] INFO: usr
0000001206 [app] INFO: 	.
0000001207 [app] INFO: 	..

An enterprising soul should be able to improve and adapt to clear files as necessary. A wise soul would recognize they should be very very very very very careful not to delete any files under sys as LFS doesn’t have access protections and perhaps consider why they need this in the first place.

1 Like
3

Actually, a clever soul would NEVER store files in the root of the Gen3 LFS! Instead, they should create their own directory that they can later recurse to only remove those files and subdirectories.

@thrmttnw, the Gen3 devices use LittleFS to store important data which must not be removed so as not to “brick” the device and have to be repaired with a JTAG programmer.

1 Like
4

Yes, creating any subdirectory at usr would be preferred. And if you do adapt this for “deleting everything under directory X” then probably force the “usr” prefix. So that delete_my_stuff("images") gets translated to the /usr/images subdirectory. And reject any path with an embedded . or .. for the same reason as it could then get back out of /usr/.

2 Likes
5

@Joel thanks, that will come in handy!

@peekay123 Oh I see. I got the impression it was user dedicated memory. I now found the EEPROM emulation is also in littleFS.

So when LFS gets corrupted, while the device is in the field, that can not be handled from user firmware.

With PublishQueueAsyncRK using LFS from it’s own thread, do I need to use a mutex or similar, when accessing EEPROM from the user thread, or is that baked in?

6

I’m not familiar with the PublishQueueAsyncRK use of LFS.

But access to the filesystem, whether through the POSIX API or the EEPROM API, acquires a lock so should be safe without any concern on your part. You can search FsLock in the Device-OS codebase if you’re curious.

7

@thrmttnw, LittleFS is quite reliable and if it get corrupted, the DeviceOS on the Boron will have bigger problems than you will!

8

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.