Strange behaviour of attributes

[klausbng]

Hello,

I have ported littlefs to the TI Tiva development kit DK-TM4C129X using a Tiva TM4C129XNCZAD Cortex-M4 CPU and a MX66L51235F serial data flash. I am using the attributes for the file creation time (using lfs_file_opencfg). Doing this, I experience a strange behaviour:

• If I first create a directory, the a file "f1" in this directory and write the attribute, this attribute doesn't show up, if I close and re-open the file. If I then create a file "f1" in the root directory, the same attribute will also show up for the other file.
• If I first create a file "f1" in the root directory, then a directory and a file "f1" within it, this second file will also have the same attribute as the file in the root directory.

This is part of my code:

• Creating a file: memset(&sAttr, 0, sizeof(sAttr)); memset(&config, 0, sizeof(config)); memset(&file, 0, sizeof(file)); sAttr.type = 1; sAttr.buffer = ×tamp; sAttr.size = sizeof(timestamp); config.attr_count = 1; config.attrs = &sAttr; err = lfs_file_opencfg(&lfs, &file, pcFilename, LFS_O_RDWR | LFS_O_CREAT | LFS_O_EXCL, &config);

• Creating a directory: err = lfs_mkdir(&lfs, pcDirname);

Filename-strings used: "f1"; "/dir/f1" Directory-strings used: "/dir1"

Is there a misunderstanding from my side or there is a bug?

Many Thanks

[lsilvaalmeida]

Hi @klausbng.

In the second time that you're opening the file, are you using the flag LFS_O_EXCL? Are you checking if there is no error on opening it? I had some user errors in the path where I was trying to search the file.

[klausbng]

Hi lsilvaalmeida, no, I didn't use this flag. The second time I am using "LFS_O_RDWR | LFS_O_APPEND". And I check the return values after each call and print out. If nobody else has the same problem, it must be on my side. Some side effects on configuration? Maybe here something is wrong? struct lfs_config sConfig = { NULL, // void *context; diskRead, // read diskProg, // prog diskErase, // erase diskSync, // sync 1, // lfs_size_t read_size 1, // lfs_size_t prog_size 4096, // lfs_size_t block_size 128, // lfs_size_t block_count 1024, // uint32_t block_cycles 64, // lfs_size_t cache_size 16, // lfs_size_t lookahead_size NULL, // void *read_buffer NULL, // void *prog_buffer NULL, // void *lookahead_buffer 0, // lfs_size_t name_max 0, // lfs_size_t file_max 0 // lfs_size_t attr_max };

Regards Klaus

[lsilvaalmeida]

Hello @klausbng. I think that have a file_max and name_max equals to zero can be source of multiple problems since lfs make comparision of the path length and this second parameter. The first one can limit the number of files in a directory, so it isn't normal have 0 as value. I think this values should assert, but I'm not the expert. Try to change these values and let us know if this solves your issue.

Also you should pass the wrapper functions addresses to the config (I dont know if you're already did it), it means &diskRead, &diskProg etc instead of just diskRead, diskProg. Maybe I'm wrong, but I think that this can change thinks.

[klausbng]

Hello, in the documentation it is written, that a it "Defaults to LFS_FILE_MAX / LFS_NAME_MAX when zero". For the first value it is 2147483647, the second 255. Same is true for LFS_ATTR_MAX (1022). For the wrapper functions: the addresses are passed. I debugged the code and they are called correctly and work. SYNC is quite simple - it just returns 0. In C using a function name in place of a pointer, this name is automatically converted into its pointer. So ptr=diskRead is identical to ptr=&diskRead.

Regards Klaus

[geky]

Hi @klausbng, thanks for creating an issue, sorry it's taken me so long to get to this one.

One thing you can do to see if it is a porting issue is to try to recreate the bug using the emulated block device (emubd) locally (this would also make it easier for me to reproduce and add to CI, and if you modify emubd to print block device operations it may help debug your driver).

I tried to reproduce the attribute issue with emubd, but it seems to be working fine. Though I'm not sure if this is because I'm not reproducing the issue correctly, if the bug was fixed in a recent patch, or if it's an issue with the driver you're using.

This was the test.c file I used, if you save it to a file you can run it with make && ./lfs: https://gist.github.com/geky/1b0659f172dc801624a7149966f3a091

[klausbng]

Hi @geky, that helped a lot: I found the issue - it was on my side. When iterating through a directory using lfs_dir_read I was using info.name, which contains only the filename, not the complete path (as documented...). Your sample program helped, I immediately saw my problem.

[geky]

Ah! Good to hear :)

[BrianRothwell]

Hi @klausbng, I have been fighting a port to the same device. Care to share your versions of littlefs_read_block, littlefs_write_block, littlefs_erase_block? I haven't been able to get past format and mount. :-(

[klausbng]

Of course, I will just attach the driver. It was derived from a similar driver for FatFS, this is why there is some similarity in the structure.

lfs_driver.zip

On the eval board you will find the MX66L51235F, on my hardware I am using an SST25VF, so I attached both drivers. I have removed some lines that I am using for switching to power-down mode with a much lower clock frequency, I hope I didn't oversee something. The only external variable that should be addressed is the clock frequence, see the definition in data.h

Regards Klaus