Create files using the same method, some files are 0x201 (inline) type and cannot be written

[Ldd309]

Hello,
In the current file system, the same method is used to create files, but several of the files cannot be written, and the size of the file is also 0, and the data in the file system is parsed, and the file type that cannot be written is 0x201 (inline), and the other file types that can be written normally are 0x202 (CTZ-struct).

Littlefs version is used: V2.5.0

How to reproduce: Unfortunately, there is no way to reproduce this problem reliably, and only one device in the same code environment has this problem.

Please ask what might be causing this issue, and is there anything that can be done to fix or avoid it, or in which version it has been fixed.

Thank you for your time and help!

[geky]

Hi @Ldd309, thanks for creating an issue.

Is this device undergoing power loss?

One behavior that often catches users by surprise is that littlefs creates a zero-length file in lfs_file_open, before the first lfs_file_sync/lfs_file_close call. If you lose power before lfs_file_sync/lfs_file_close you can end up seeing the zero-length file where you might be expecting data. Note though you will never see partially written data.

The reason for this annoying behavior is we need to store the filename somewhere between lfs_file_open and lfs_file_sync/lfs_file_close. There's work ongoing to add a sort of temporary+invisible "orphan" file so this case behaves more intuitively, but it will take some time before the feature is available.

I think #908 is the same issue.

[Ldd309]

Hello @geky,
Thank you for your reply, but the device did not lose power and these files can no longer be written in the future.

[geky]

That is strange then. Zero-length files could also be created if a file was opened but never closed. Or if there was memory corruption.

But if these files can't be written, that is curious. Do you can an error when trying to write to the files?

The fact that these files are all next to each others suggests they could be in the same metadata-log, which might mean the metadata-log was corrupted somehow.

[Ldd309]

I tried dump the file system data on the device, and mounted it on linux through lfs-fuse for test, linux can write these data normally. I think there may be a problem with flash?

[geky]

That would be explained by a block returning incorrect data. Was this device under heavy use? If not maybe it was a manufacturing defect?

littlefs does extend the lifetime of the device by distributing wear it across all blocks in the device, but littlefs doesn't have mechanisms to detect or correct errors when they do happen. There's some long term plans to add error detection+correction, but they are currently just plans.

Some users have had success putting checksums in the block device layer to detect errors, if you need to protect against this type of failure: #843