FS/littlefs: it is possible to write to already deleted file

[nvlsianpu]

Describe the bug
It is possible to write to file which was removed if it had been opened before removal.

To Reproduce
fs_open(&f, "lfs1/fname", FS_O_CREATE | FS_O_WRITE);
fs_write(&f, data, length);
fs_unlink("lfs1/fname");
fs_write(&f, data, length); /* will succedd */

Expected behavior
shouldn't be possible to write to a unlinked file

Alternative Expected behavior
the file which is opened can't be unlinked.

Impact
Thread which writes to the file might be not aware that another thread deleted the file. This cause data lost.

[nvlsianpu]

@pabigot I encountered this issue while testing FS log backend.

[pabigot]

I think that behavior is correct: unlinking simply removes the directory entry, it won't invalidate the file.

That idiom has long been used on Unix systems to create a temporary file to hold data so the space is reclaimed when the last open descriptor closes.

[pabigot]

IOW, I don't think this is a bug, unless the FS API explicitly requires a failure when writing to an open file where the underlying storage has been deleted. And if that's so, it may not be something that can be fixed.

[nvlsianpu]

cc @de-nordic

[nvlsianpu]

Maybe expected behavior should be that the file which is opened can't be unlinked.

[de-nordic]

@nvlsianpu , @pabigot

This is VFS design compromise that is deficiency when parallel access to file system is exercised.
It has never been specified what should happen when opened file is deleted, and the issue also does exists with read operations, or files opened as read-only.
I do not thin that this has been predicted to be happening as probably the original idea has been that the developer is the only one to have control on files, their existence and their access time-line, which means that the developer is responsible for not removing files he is working on.

Maybe expected behavior should be that the file which is opened can't be unlinked.

This will require rework of VFS, because the VFS does not hold registry of all opened files, as the user is responsible for providing structures for file system information, so it is not aware of files that are currently opened or being accessed.
The LittleFS back-end in VFS is responsible for allocating and providing to LittleFS driver, file information structures which means that information for each opened file is stored separately and not within the LittleFS back-end.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.