You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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: