-
Notifications
You must be signed in to change notification settings - Fork 48
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
Allow a recursive option on rmdir #71
Comments
Needed! |
@SaadBazaz do you want to contribute? |
@jcubic I can try giving it a go. Any pointers to where I can start? |
You should just get familiar with the code, it was a while when I read the code I don't remember where you should start. But there are not much code in this project. |
FWIW I ran into this issue and just used |
Yes, it will not actually delete the files, they will just become inaccessible, because their parent is removed. They will still take up disk space, however, like you said. |
mkdir also missing recursive option |
then just "await rmdir(dir)" after "await clearDirectory(dir)" |
The
rmdir
function in newer versions of Node allows for arecursive
option that when set totrue
makes the command behave more like arm -rf
, which I think can be very useful in many situations (such as deleting a cloned but no longer needed git repo for example).The documentation of
lightning-fs
suggests that itsrmdir
also takes an options object, but I browsing through the source I couldn’t find anything that seemed to be using that object (I might have missed something though 😅). I feel like adding a nativerecursive
option could really benefit the library and perhaps would even allow for a more efficient way than a recursive "rimraf" implemented on top of the library, since if I understood the structure oflightning-fs
correctly it should be possible to just gather a list of all inodes contained in the directory, delete them and then delete the directory itself in a single transaction, right?Sorry if that suggested solution is useless, but I hope the rest of my point still stands.
Keep up the great work! 🎉
The text was updated successfully, but these errors were encountered: