lfs_remove doesn't have unlink/rmdir distinction about littlefs HOT 4 OPEN

i was writing a posix-like api on the top of lfs.
yes, lfs_stat can do the trick and that's what i'm using right now.
w/ threads, it's a bit racy w/o an extra locking though.
anyway, this is not too important.
if you prefer to have less API, it perfectly makes sense.

from littlefs.

ok. i will probably take that route. (stop using LFS_THREADSAFE)
thank you.

from littlefs.

Hi @yamt, thanks for creating an issue.

I guess my question, is there value in this outside of compatibility reasons? You can check the file-type with lfs_stat before removing after all.

littlefs needs some limit on what APIs get added, to avoid feature creep.

from littlefs.

w/ threads, it's a bit racy w/o an extra locking though.

I was thinking about this. It is one point for separate unlink/rmdir.

But I think the main situation where this would come up is compat layers, such as your case. If you're writing a compat layer I think it may be better to handle the mutex yourself, and leave littlefs's lock/unlock as noops. This would give you the most control, in case you need to combine other operations.

lock/unlock in littlefs are really only for easier use if you don't want to write your own fs API/OS layer. littlefs doesn't interact with threads (and probably never will?) otherwise.

from littlefs.