-
Notifications
You must be signed in to change notification settings - Fork 769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lfs_remove doesn't have unlink/rmdir distinction #955
Comments
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 littlefs needs some limit on what APIs get added, to avoid feature creep. |
i was writing a posix-like api on the top of lfs. |
I was thinking about this. It is one point for separate 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. |
ok. i will probably take that route. (stop using LFS_THREADSAFE) |
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.
The text was updated successfully, but these errors were encountered: