You are not running with privileges that allow symlinking, so Phoenix has to copy the priv directory instead of link it. However with it being copied creates race conditions. Assuming you are running recent versions of Phoenix/Elixir you should have got a message in your terminal that stated that if you are not running without symlink privileges or something like that they you will experience significant performance degradation during development in addition to various errors. The error you get of ‘not owner’ is because the Windows file system has not finished synching files in the background so it is ‘owned’ by ‘SYSTEM’ at that second, but it reverts back to you when it is done (most of the time, if a copy happens while another is still synching in the background it can get perma-stuck). Yes NTFS sucks.

Either give your user access to permission to create symlinks, or run the server with admin permissions. It is a limitation of Windows, it cannot keep up with the code reloading and gets stuck like that when it happens rapidly, but by giving the server symlink (or admin) permissions (Why does windows not give it by default?!? Stupid…) then Phoenix can work-around the issue by just symlinking so there is only ever one copy.

Source: I was the one that discovered this issue, it is native to Windows and how fast the BEAM compiles (too fast) and found the work-around, consequently I was the one that suggested that the message be added to the terminal (and it still reminds me to this day when I forget to elevate the server process). ^.^

EDIT: You may need to manually delete that directory ‘one-more-time’ to let the symlink happen, but that is a toss-up on whether it is required or not too.

Hi. Also new to Phoenix. Maybe there’s something related to Brunch (node) running as Administrator. I’m not much sure on this but maybe when building (also copies priv folder to _build folder), it can delete because is not the owner.

Not totally sure if this is the issue, but it may be a Node related issue.

Thanks for the detailed explanation. Running the shell as Administrator fixed it for the reasons you mentioned.

Nope, not brunch or node or even the BEAM, just how Windows works with lots of file changes very fast.

Awesome, glad to help.

Love what NTFS still does. I recall some weird stuff when was developing PHP + Composer on Windows. When wanted to delete the vendor folder, in some cases there were many files nested in some cases with long names, and NTFS just failed on those cases.