lfs_remove doesn't have unlink/rmdir distinction

[yamt]

posix has separate functions to remove regular files and directories; unlink and rmdir. sometimes it's convenient to have the distinction, especially when using posix-style applications. maybe lfs_remove can have a flag to choose the behavior, similarly to AT_REMOVEDIR of posix unlinkat.

[geky]

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.

[yamt]

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.

[geky]

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.

[yamt]

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