This is driving me up the wall. #Node #JavaScript
1. I open, write some stuff to, and close a file. I've waited for close events on file streams, explicitly closed/waited, what not. It's closed*.
2. I delete the file (cf. unlink). Waited for that callback before proceeding.
3. A unit test calls stat on the file to see if it's really gone. Unix agrees, ENOENT. #Windows throws friggin' EPERM. EPERM! Even when I poll for awhile, always EPERM.
* Except it's not. Process Explorer shows an open handle. 😐
@Riley Yeah, I've heard of that. I think I have the tools to find out exactly what supposedly has the file open... but goodness, I really have no idea what's going on here.
@zigg is the handle your process' though? What if it's something unexpected like amthe system file indexer/ search engine? :)
@cathal Yeah, it definitely belongs to the node.exe that I believe is running the unit tests.
@zigg Something evil is afoot
@cathal It doesn't help that I've been down all the GitHub rabbit holes and best practice seems to be "wait for the EPERM to disappear with some backoff polling"
Buddy, I polled for a full minute. 😓
@zigg I had a related nightmare once with a device that was "programmed" by writing to a file, and status "polled" by reading to a file. Problem was, the device pretended to be a USB mass storage device, containing those two files. So, after you read the file once, and the system sees no writes on the file, it aggressively caches and you can't read a new status. Needs a special syscall to prevent caching, was super brittle to work-around until Python 3.5. Headaches!
@cathal Oh wow, my sympathies 😣
@zigg Somehow I feel that your problem might be worse than mine! :D It was an interesting learning experience for me, at least.
@zigg
(”Noone expects the search engine-quisition!")
@zigg Windows has had a problem since time immemorial where it claims a file is open in something even though it isn't.