node.js fs module was originally designed to copy linux's standard way of handling files. This means for deleteing files using the unlink functionality. For Windows, however, unlink operates differently - differently enough that I encountered several issues with unlink.
Why on Windows? Electron, mostly - I needed to handle a file post-creation via a child_process (in this case, a terminal execution of ffmpeg).
Windows unlink works by using ZwSetInformation (a low level Windows API/function) to set a file property DeleteFile to TRUE. Windows will then eventually, once the file is no longer being accessed by any process "delete" the file in whatever way it is wont to do (Recycle Bin versus full delete, etc). However, even if a child process created the file, it seems that the file can possibly be linked back to the parent process, preventing the parent process from ever actually deleting the file.
Even if the unlink process fires correctly, if Windows believes the file is still being accessed by other processes, it will not remove the file. This causes issues if you attempt to create a file under the same name later.
In my case, I would have a generic "output" recording file named out.mp4 that ffmpeg was creating. After copying and then removing the file to a processing directory, I would later record future output to the same file name. This caused issues if the "unlink" problem occured - ffmpeg would not / could not overwrite the file
If this is occuring to you, first see if you can figure out what process or where the file is being held open.
Barring that, I suggest not to use static file destinations for file creation and management. Consider my use case - saving to a set file, and then moving that file over for processing post recording. A simple fix that would prevent this issue from stopping future recordings would to generate a random file destination for file creation. Then, even if I can't safely remove a previous recording, it does not harm future recordings.
Hope this helps someone.