Mysterious Disappearance of Haxe Std Files

[jgranick]

I am installing Haxe again for the twentieth (?) time, due to missing files

HaxeFoundation/haxe#5577

Is there a chance this is related to FlashDevelop in some way? Closing the application halfway in a build, something to do with find and replace?

It usually appears in js.html.* classes (since there are so many), eventually a file disappears, such as "XPathResult", and I need to install Haxe again to fix. There was a suggestion FlashDevelop could be related, but I'm not sure. What do you think?

[Neverbirth]

Wow, that's crazy. Find in files shouldn't do something like that, so I don't think this could be related to FlashDevelop, also I guess we would have got a lot of reports but in software one can never know for sure.

It's true that FD seems to be locking some files and folders for some computers more than others, and I would like to check this in the future, but I never saw in my career that locking some folder or file like FD does would end in files deleted.

You could try to use Process Monitor to catch where this comes from. You should set some filters because it logs tons of stuff.

[Gama11]

We've gotten multiple reports of this sort of issue in the HaxeFlixel forums recently:

• http://forum.haxeflixel.com/topic/472/html5-for-haxeflixel
• http://forum.haxeflixel.com/topic/459/can-t-build-to-html5

I've also had this happen to myself quite frequently when I still used FD (I was running Haxe installers a lot to switch between release and dev builds). Closing FD always seemed to fix the installation then.

[Gama11]

And yet another case of this:

• http://community.openfl.org/t/solved-build-error-with-html5-target/8889/2

[Neverbirth]

My guess is that the watchers themselves are working fine (otherwise I would have got similar problems in other completely different personal projects where I also use them, and with a quite big user base), but for some reason on some specific changes FD wants to reparse some file inside a folder that is being deleted and that's when the lock happens and causes this problem. Although it could be that the way watchers are implemented in here is wrong.

I would like to look into this, but sadly it's something that it's not happening on my environment so for now I spend the really small time I have in other tasks that affect me more...

[Neverbirth]

I will do my best to have a solution for this during this week, as I have now a project that seems to be a good base to find the root cause for this issue.

[Neverbirth]

I think I already found the cause for the issue, but I may need some extra time for a proper solution.

[Neverbirth]

Just an update: I have changes locally that should fix this issue, but I want to give it some final review before committing. Hopefully I will push it tomorrow.

EDIT: I spent the full day with a build using the fix. I found some flaws, so I have to look into them.