phoenixframework / phoenix_live_reload

Provides live-reload functionality for Phoenix
MIT License
315 stars 90 forks source link

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

Closed zhengxiaoyao0716 closed 6 years ago

zhengxiaoyao0716 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

OvermindDL1 commented 6 years ago

Ah, yes indeed it is still there:

https://github.com/phoenixframework/phoenix/blob/8dbb2609dc933b367b8463a4cee62d2f3cde0f8d/lib/phoenix/code_reloader/server.ex#L37

And:

https://github.com/phoenixframework/phoenix/blob/8dbb2609dc933b367b8463a4cee62d2f3cde0f8d/lib/phoenix/code_reloader/server.ex#L81

chrismccord commented 6 years ago

ah, beautiful. Thanks!

zhengxiaoyao0716 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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.