Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
readdirSync returns deleted folder #4760
The function readdirSync returns folder that was already deleted.
steps to reproduce:
The file is deleted immediately after calling the rmdirSync. Most of the file managers (including Windows Explorer) watch the file system changes. If they find the current folder deleted they go up to the parent folder. It's a common behavior and it's the same as in my case - the file manager goes up to app folder.
If you run Command prompt and go to the view folder before running the script, you get the exception:
So, if something is holding/locking the folder, you get an exception. If not, shouldn't it wait for the file system since the method is synchronous? (the Sync postfix in the name rmdirSync)
I can reproduce it on Windows 10.
It's not a bug in Node or libuv, these are correctly returning the current state of the filesystem.
It's a race condition that's just part of working with a filesystem on Windows. Filesystems don't always provide much guarantees as to order and timing of filesystem operations etc. and the user needs to be aware of this.
I think this is what's happening, but I might be wrong:
If it's critical for the user to enforce order, persistence etc. then they should just call
I see that in the same way as @jorangreef.
NodeJs documentation says the method fsyncSync has an argument called fd, nothing more. So I guess the fd is a file descriptor. How can I get the file descriptor of the folder that is going to be deleted by rmdirSync to pass it later to fsyncSync to wait for releasing all the handles?
Does the fsyncSync method actually wait for releasing all the handles of the folder or it just produces 1 ms time loss which causes returning expected result?
@pavelzaruba I think you're right. In this case maybe