@geky as per our previous conversation about upgrade to V2 from main repo here is a script for autorenaming all required files. Just create this file in main repo, run and copy the result back this repo

#!/bin/bash

for fullpath in $(find ./ -type f); do
    # echo "Processing file ${fullpath}"

    # replace string lfs with lfs2 (it renames lfs1 to lfs21, correction is applied)
    sed -i -e 's/lfs/lfs2/g;s/LFS/LFS2/g;s/lfs21/lfs2/g;s/LFS21/LFS2/g' $fullpath

    # rename files begins with lfs* to lfs2*
    filename="${fullpath##*/}"

    if  [[ $filename == lfs* ]]; then
        new_path="${fullpath:0:${#fullpath} - ${#filename}}${filename:0:3}2${filename:3}"
        mv $fullpath $new_path
        # echo "Renamed ${fullpath} -> ${new_path}"
    fi
done

Hi,

We are using lfs2 along with Mbed-OS and FlashIAP for the STM32G0 target. During our usage in development we've experienced no issue running the application. But after the deployment stage in a client, it occurred that power supply was cutoff from about 100 devices and all experienced the same outcome. They all got stuck on LittleFS initialization, more precisely in the lfs2_dir_fetchmatch while(true) loop, which is called by lfs2_mount. We can't understand exactly why this is happening, and we can't debug further. So far, with the help of GDB and OpenOCD, the only clue we could get is that in normal operation it should in some moment break in the following statement:

 if (!lfs2_tag_isvalid(tag)) {
    dir->erased = (lfs2_tag_type1(ptag) == LFS2_TYPE_CRC &&
            dir->off % lfs2->cfg->prog_size == 0);
    break;
}

We are not sure if the application is just getting stuck in an infinite loop or if some internal error are being thrown out and then the board stops.

I'm attaching a print from GDB server with its backtrace until the application reaches the watchdog timeout handler.

https://github.com/ARMmbed/mbed-littlefs/blob/master/TESTS/filesystem/parallel/main.cpp#L295

As per the test case above, remove to file opened for (write/read) is successful without closing.
Shouldn't filesystem deny removal of files in use?

https://github.com/ARMmbed/mbed-littlefs/blob/master/TESTS/filesystem/files/main.cpp#L120
I would recommend to have single test case function with with configurable parameters size and chunk. We can than have all cases covered with multiple test cases.

Just what the title says!

I am having query I saw few example in which somwhere used frpintf , fwrite to write to a file in littlefs.

1. Just wanted to know which of them invokes lfs2_file_write ?
2. Whether writing to a littlefs file using fwrite or fprintf involves virtual filesytem layer?

It would be useful if the only limit was available space and not a fixed number of blocks. Currently you get an assert on line 1875 in lfs.c if the block device contains less than 32 blocks.

Hello,

It seems that if I use very small embedded with only 5 blocks,
then after filling a file in size of 1 block, I can't open another file - as if it can't actually use all the blocks...
Why can't we use all available blocks ? And is it that 5 blocks are used for other purpose ?

Thanks

The following code demonstrates a bug in LittleFS.
A file is created, written, closed with no errors, but seems to be empty (lfs_stat() shows zero size, lfs_file_read() returns zero).
In the sample below errorCnt increments every 5th iteration. The bug recurrence actually depends on the block_size. The problem occurs when LFS allocates new block to extend the directory.
Reproduced on both HeapBlockDevice and lfs_emubd.

HeapBlockDevice hbd(1024 * 512, 128);
hbd.init();

lfs_t fs = {0};
lfs_config cfg = {0};

cfg.context = &hbd;
cfg.read = lfs_bd_read;
cfg.prog = lfs_bd_prog;
cfg.erase = lfs_bd_erase;
cfg.sync = lfs_bd_sync;
cfg.read_size = hbd.get_read_size();
cfg.prog_size = hbd.get_program_size();
cfg.block_size = hbd.get_erase_size();
cfg.block_count = hbd.size() / cfg.block_size;
cfg.lookahead = 32 * ((cfg.block_count + 31) / 32);

lfs_format(&fs, &cfg);
lfs_mount(&fs, &cfg);

for (int i = 0; i < 32; ++i)
{
	char name[256];
	snprintf(name, 256, "TestFile%u", i);
	lfs_file_t ff;
	lfs_file_open(&fs, &ff, name, LFS_O_WRONLY | LFS_O_CREAT);
	lfs_file_write(&fs, &ff, "Hello World", 11);
	lfs_file_close(&fs, &ff);

	lfs_info info;
	int err = lfs_stat(&fs, name, &info);
	if(0 == err)
	{
		if(info.size != 11)
		{
			static int errorCnt = 0;
			errorCnt++;
		}
	}
}
lfs_unmount(&fs);
hbd.deinit();

Test cases in TESTS\filesystem\parallel folder are not actually read/write to files in parallel test case. It is actually read/write to multiple files sequentially.