Closed zhengxiaoyao0716 closed 6 years ago
Maybe you can take a try, the project ispublic, here the repository: honeycomb-adventure . And here my environment: Windows 10 Version 1703, Enterprise edition.
Hoped this information can make some help.
Thank you @zhengxiaoyao0716! It seems this issue is specific to Windows. Since we can't properly use symlinks on Windows, we need to copy the files and something is happening when we copy them.
Pinging @OvermindDL1 in case he has any ideas what may be happening.
Well, I'm glad that I could help you. Since this problem may caused by symlinks
and only happened on Windows, I'll try to working on other system for the moment.
This is precisely the problem. If you enable symlinks for your user in windows (or run phoenix as administrator) then it works fine. I did a lot of research on that when I had the issue last year, it's documented around here somewhere, but that is the way to solve it on Windows... ^.^;
The issue is that Windows doesn't quite flush and unlock the file and phoenix is too fast to acquire the new files, this becomes especially larger of a problem if you use any virus program at all as their file listen hook slows down file access as well since Windows does not have a well made COW or well-journaled file system.
I thought a message was added at load time that warned you exactly of this and how to fix it as well, wasn't it?
The issue is that... phoenix is too fast ...
:D In all seriousness I don't think we can help this one on our end, but maybe we can include docs somewhere for windows to recommend running as admin?
:D In all seriousness I don't think we can help this one on our end
Lol, more that the beam is too fast because it does not listen for the windows event that says a flush is complete, and even then if an anti-virus exists then it will lock the file before it could be re-opened anyway, thus still causing the same issue... ^.^;
but maybe we can include docs somewhere for windows to recommend running as admin?
I thought it was already documented when a person loads a phoenix server in dev mode on windows, it should print a good sized paragraph talking about exactly this issue and what to do to work around it. I know I last saw it when I last ran the server on windows (thankfully I finally convinced my job to migrate the servers fully to linux, red hat but eh).
ah, beautiful. Thanks!
@OvermindDL1 Thanks, I found the message, it is just in the third screenshots of the first floor, but I didn't realize it at first that this was the reason of this problem.
@OvermindDL1 As the message guide, I tried to run phx.server as Administrator
, and found the priv
folder in _build
now is a symbol link, and seems no problems.
I have a small idea, the only thing we need is to create some symbol links as Administrator
identity for those folders, but we don't need to create them each times at the phx.server
task.
We can provide another task to allow user create those symlinks as Administrator
identity, then each time that phx.server
start, check those symlinks and if they are not exist, give a tip to users that they need manual execute the task as Administrator
to generate those symlinks.
Although this way may not the best method and user have to take an extra step, I think this is the most simple patch,.
Umm, perhaps we have a easier choise, just change the message like you need to run this task as Administrator at least once time
, if user did this and the symbol links already exist, hide the message.
if user did this and the symbol links already exist, hide the message.
Hmm, a check to see if the symlink already exists and points to the correct location might indeed be a good quality-of-life workaround, and only be a line or two of code to implement (if the BEAM has a command to query that information, I'm not actually sure, never used it...). You should PR it? :-)
it is just in the third screenshots of the first floor, but I didn't realize it at first that this was the reason of this problem.
Also, heh, it is, I missed it too. I could have sworn it was red when I had it back on Windows.
@OvermindDL1 That is my PR , I tested those code on my windows system locally and they works well, but maybe we need more test on other systems.
In addition, I tried some terminals I can found on my Win10, powershell, cmd, mingw. But none of them can render color with [warn] logger. In my VSCode debug console, the message starts with warning
is red, but [warn] logs still can't.
In addition, I tried some terminals I can found on my Win10, powershell, cmd, mingw. But none of them can render color with [warn] logger. In my VSCode debug console, the message starts with warning is red, but [warn] logs still can't.
For note, none of what you listed are terminals but rather are shells. The terminal you were probably using was 'command' (which is pretty horrible, and even Win10 is trying to phase it out). I tend to use conemu as the terminal myself though.
I wrote some codes, they were built succeeded and output into
./priv/static/script/
:But, if I change my codes and trigger the
live-hot
, sometimes the copied file in_build/dev/lib/my_app_path/priv/static/
would be cleared:This doesn't happened every times, but I think it maybe due to the size of the file was too large and this plugin reload the file early.
I took a try, every time I clear the terminal manual and trigger reload, then record if the file in
_build
directory was cleared:First, start the server, the file was correctly and page looks well:
Clear the terminal and trigger a reload:
Repeat last step sometimes until the problem happend:
After compared those too case, we can see the different, while the logger looks like those, everything works well:
And if the log looks like those, the finally built file would be cleared:
I hope that this problem could be fixed as soon as possible, it really interfere my work, thank you.