lfs_file_seek and lfs_file_write succeed even if the file is removed while open

[shahawi-sumup]

Hello,

Let's assume we have 2 thread
Thread1: Opened a file and continuously seek and append data to it.
Thread2: deleted the same file opened and in use by Thread1

I can see that the file is not there on the flash after lfs_remove but functions lfs_file_seek and lfs_file_write doesn't report errors.

#define LFS_VERSION 0x00020004
#define LFS_DISK_VERSION 0x00020000

Could you please help me understand this behavior and if it is fixed in a later version ?
I tried to find a similar issue but couldn't found any.

Thanks in advance :)

[geky]

Hi @shahawi-sumup,

In general, littlefs tries to match Linux/POSIX behavior where possible, since this is what a lot of developers expect from a filesystem, even if the behavior is sometimes unintuitive.

In this case, the storage for a file is reserved until both:

1. The file is removed (unlink in Linux/POSIX).
2. All open file handles are closed.

In this model, it's not really a bug for Thread1 to be able to still write to the file, the data just doesn't go anywhere when closed.

This has some trade offs. On one hand, it can create surprising behavior like this, and may end up with more storage temporarily resrved. On the other hand, it can make some multithreaded cases easier, such as opening a file for reading without worrying about a thread removing the file mid-read.

---

Sidenote: Reading up on things, it seems there was also a proposal for Linux to add a sort of flinkcall that acted as the inverse of unlink, i.e. relink unlink files back into the filesystem (src).

That proposal was shot down for security reasons. littlefs doesn't really have the same security concerns, so it could in theory be added here, but I don't know if there's much demand for such a function.

[shahawi-sumup]

Thanks @geky, That answers my question.