Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes the built file will be empty after live reload. #67

Closed
zhengxiaoyao0716 opened this issue Dec 13, 2017 · 17 comments
Closed

Sometimes the built file will be empty after live reload. #67

zhengxiaoyao0716 opened this issue Dec 13, 2017 · 17 comments

Comments

@zhengxiaoyao0716
Copy link

I wrote some codes, they were built succeeded and output into ./priv/static/script/:
image

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:
image

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:
image

Clear the terminal and trigger a reload:
image

Repeat last step sometimes until the problem happend:
image


After compared those too case, we can see the different, while the logger looks like those, everything works well:
image

And if the log looks like those, the finally built file would be cleared:
image


I hope that this problem could be fixed as soon as possible, it really interfere my work, thank you.

@zhengxiaoyao0716
Copy link
Author

Maybe you can take a try, the project ispublic, here the repository: honeycomb-adventure .
And here my environment:
image
Windows 10 Version 1703, Enterprise edition.

Hoped this information can make some help.

@josevalim
Copy link
Member

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.

@zhengxiaoyao0716
Copy link
Author

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.

@OvermindDL1
Copy link

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.

@OvermindDL1
Copy link

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?

@chrismccord
Copy link
Member

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?

@OvermindDL1
Copy link

OvermindDL1 commented Dec 13, 2017

: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).

@chrismccord
Copy link
Member

ah, beautiful. Thanks!

@zhengxiaoyao0716
Copy link
Author

@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.

@zhengxiaoyao0716
Copy link
Author

@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.
image

@zhengxiaoyao0716
Copy link
Author

zhengxiaoyao0716 commented Dec 14, 2017

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,.

@zhengxiaoyao0716
Copy link
Author

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.

@OvermindDL1
Copy link

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? :-)

@OvermindDL1
Copy link

OvermindDL1 commented Dec 14, 2017

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.

@zhengxiaoyao0716
Copy link
Author

@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.

@OvermindDL1
Copy link

OvermindDL1 commented Dec 27, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants