Giters

microsoft / WSL

Issues found on WSL

Home Page:https://docs.microsoft.com/windows/wsl

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Filesystem watchers like libinotify do not work

mablae opened this issue Β· comments

commented

The whole /proc/sys/fs structure is missing, too.

inotitywait does not get triggered by filesystem changes.

commented

Thanks for reporting the issue.

Currently, only portions of procfs are implemented and there is limited inotify support. To get this on our priority list can you add it to our [UserVoice](https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/category/161892-bash page) page? Thanks again for trying out WSL!

commented

@patryk9200 Thanks!

commented

All of the node.js watch functions that I've tried fail on EPERM. I've ensured that all files and directories that it's trying to access have the proper ownership group and user. I even tried running watch tasks as the root user, and I receive the same eperm issue. I've also made sure that all of the files are listed inside the linux subsystem, and that I'm not trying to watch files mounted to /mnt/c/

commented

JSMike: It does not work. This is why we opened this issue πŸ˜„

commented

yes, I was just trying to add detail

commented

Thanks for the feedback. Inotify will not be fully supported in the Anniversary update, but we are tracking the work for future insider builds. If you haven't already, please vote on the user voice page for inotify (https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13469097-support-for-filesystem-watchers-like-inotify).

commented

I'm in the same boat #697 .. I have to go back to CygWin until we can see this resolved. I am very excited about this in Windows though. I spent a good day trying to get our dev kit working, and from what I can tell, the build is very solid. But yes, I also fell into missing proc/sys/net problems with mongo too so we will have to come back once these features are enabled.

commented

@SRGOM -- I don't know that there's automated telemetry, but users can vote on issues here:

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/category/161892-bash

So Microsoft does have some information about both which features people want to use and how much they care about them.

On that note -- have you voted for this issue there? It's relatively high on the list.

commented

Just posting here to show how much I would love to see this feature implemented

commented

@meffect if you haven't already, you should throw three votes at it on the UserVoice page linked above. It has gotten a lot of traction lately, but hasn't yet been tagged by the MS team.

commented

how about how to work around the issue in the meantime??? for example what config settings etc, need to be used for a basic rails 5x install?

commented

I generated my app with --skip-spring --skip-listen. Then when I run guard I use guard -p to force polling mode. I thought about trying to get spork running instead of spring, but I haven't done that yet. Guard without Spring does make TDD a slow and painful process, though. So I love seeing that UserVoice page getting more votes.

commented

Thanks @jwsloan

If you have already generated a rails app, here is what you have to do to fix:

  1. comment out this gems listen, spring, and spring-watcher-listen in the Gemfile:
  #gem 'listen', '~> 3.0.5'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  #gem 'spring'
  #gem 'spring-watcher-listen', '~> 2.0.0'

I am not sure you have to comment out spring / spring-watcher-listen, but that works for me...

Then in the development.rb comment out this line:

  #config.file_watcher = ActiveSupport::EventedFileUpdateChecker

and of course bundle install...

commented

Good call on the file_watcher config, @catmando. I forgot about that part. I had to do that as well.

commented

@jwsloan Yep I gave it 3 votes. Imo, it looks more important than some of the ones above it so hopefully microsoft will tag it soon

commented

My currently blocking issue is writing an web application. typescript -watch and gulp -watch no workie. My way around it is to use node/npm windows binaries for gulp and typescript. the work around is ok, but not ideal for me because I use conemu to open 4 bash terminals inside a single window. i dont really like having to open a second window to call windows binaries for various reasons, mainly extra screen real estate needed. Also i'd much prefer to not have those windows binaries installed at all on my machine and just have the linux ones.

But ya there seem to be many other issues out there where you cant really work around them

commented

Personally the workaround I used with a rails 5 application was to modify the file_watcher config in development.rb so that it can be disabled with an environment variable.

config.file_watcher = ActiveSupport::EventedFileUpdateChecker unless ENV['NO_INOTIFY']

Then set the the NO_INOTIFY environment variable in my .zshrc. That way one can still easily collaborate with people not using WSL, or just dev on other machines without Gemfile mess :)

I didn't need to do anything with the Gemfile at all here, it seemed to fall back to polling nicely.

commented

Thanks for the info, @bluefantail. Are you using Spring with that setup?οΏ½

commented

Yea I am, I initially thought that would be an issue as well and tried re-bundling without it (unsuccessfully). Disabling the file_watcher seemed to do the job, without the need for disabling spring at all. I'm newish to rails, but I can only presume if spring is an issue, the config also disables the spring-listen file watchers as well, or something like that. This is the Gemfile in question https://github.com/bluefantail/bathtub/blob/master/Gemfile

commented

Major blocker for any modern web dev workflow.

commented

Voted on UserVoice (glad to see it high on the list there) but, yeah... oof. I was over the moon excited for Bash on Windows until I slammed into this reality. As everyone has said, this impacts a significant slice of modern web development tooling.

🍻 praying for a fix in the near future 🍻

commented

@bluefantail: It looks like config.file_watcher = ActiveSupport::FileUpdateChecker may be a better workaround then actually removing the config line. FileUpdateChecker does not cause the same issue as EventedFileUpdateChecker.

That will allow you to be able to run rails server, and you should still get reloaded assets during local development, but it will not help with running rails test. With Spring loaded, that still is causing me issues. TDD becomes very tedious without Spring...

commented

Just a comment noting I've run into the EPERM error with nodejs+grunt-contrib-watch ... it fails so badly you can't even ctrl+c/ctrl+d out, you have to kill WSL entirely.

Like other commenters, it's a blocker to actually using WSL for production level dev. Not trying to be difficult, just indicating the severity/importance. Have voted on user voice as well.

commented

Hey.
I think I might have run into the same problem with EPERM when using Ember.js, which uses NodeWatcher or facebook watchman.

commented

I found a workaround for this, which may help you all out.

The issue is that the watch function is using filesystem events that are not currently being exposed to the windows 10 bash shell. Workaround, in short, is to poll for changes instead of listening for events.

For those of you using gulp, you use the gulp-watch package:

var watch       = require('gulp-watch');

gulp.task('sass', function() {
   //Compile my sass
});
gulp.task('serve', ['sass'], function() {
   //Watch for changes and run sass task
   watch("./scss/**/*.scss", {usePolling:true}, function(){
      gulp.start('sass');
    });
});

gulp.task('default', ['serve']);

The gulp watch package is basically a gulp wrapper for chokidar, which you should also be able to use as a replacement for node's watch feature. Pass it the {usePolling:true} parameter and you're golden.

Or if you're running jekyll in ruby, you can just use a flag like so:

#jekyll serve --force_polling

I hope that helps in the meantime while we wait for better support!

commented

You mean you found the work around I already mentioned on our tracker?

commented

We've finished implementing inotify internally, now we just need to wait for it to hit the insider builds. Note that we can only report events that are triggered inside WSL (both DrvFS and VolFs are fine). If you use Windows Notepad++ to make changes, we won't be able to report it.

commented

@envygeeks There are a few mentions of falling back to polling in this thread that predate your jekyl/jekyl reference (including an UserVoice comment from August 5th), no need to be rude to contributors. I'm sure somebody will appreciate Sean's particular presentation of the workaround (conveniently inline on this thread).

commented

@JasonLinMS Thanks for the update! Is the caveat that changes must occur within WSL permanent, or is there hope for changes made from [insert favorite Windows editor/IDE here] will be picked up?

commented

@awkaiser Thanks for waiting so long for this! Honestly, implementing inotify for file changes from Windows is a lot more complicated, since WSL can't see those changes, and because Windows vs Linux file operation semantics differ greatly. Unfortunately, the likelihood of this support coming soon is extremely low.

commented

@envygeeks Right, That is the same workaround for Jekyll that you had mentioned earlier (though I had not clicked your backlink until now--apologies).

Regardless, my focus was on a gulp implementation and since I couldn't find a completed solution anywhere else, I figured I'd post what I made here so others in my same situation could save the hour or so of trial and error and have something that works.

commented

@seanriceaz Only issue I have with your post is when you said "I found a workaround for this". This implies you found a workaround for the fundamental cause behind Issue #216 . However that is not true. You are presenting an alternative method of watching the file system for changes when using gulp. This undermines the severity of the fundamental issue and also makes light of other scenarios where gulp can not be used, does not want to be used, or should not be used, in my opinion.

commented

@meffect If you're going to split hairs like that, please recognize that "a workaround" is not the same as "the workaround" and "may help" is not the same as "will help." Gulp isn't right for everyone in all cases but it is a very popular tool, and leaving a trail of potentially helpful breadcrumbs for affected developers isn't hurting anyone on this thread. I mean, I don't use Gulp, am not annoyed by Sean's contribution, and feel like it's a bit of a stretch to assert that he's "undermining the severity of the fundamental issue." I'd assume that anyone who has hit a brick wall and discovered this Github Issue while troubleshooting is probably aware of the severity of this issue.

commented

@JasonLinMS Bridging the two systems would certainly be a challenge, but good to know it's not completely off the table, just delayed indefinitely until some wizard invents a clever solution. Looking forward to this first step landing.

commented

My understanding from what @JasonLinMS is saying is that the upcoming fix will not be able to watch for changes made to files inside your Windows drive mounts (e.g. /mnt/c). If that's the case, and we want to use Windows tools to edit our files, what's the proposed developer workflow?

commented

@awkaiser from what @JasonLinMS said:

We've finished implementing inotify internally, now we just need to wait for it to hit the insider builds. Note that we can only report events that are triggered inside WSL (both DrvFS and VolFs are fine). If you use Windows Notepad++ to make changes, we won't be able to report it.

you can change files in /mnt/c, but you can't change them using Windows programs. (or at least you won't get a notification)

I'm more curious about this statement, though:

implementing inotify for file changes from Windows is a lot more complicated, since WSL can't see those changes, and because Windows vs Linux file operation semantics differ greatly

So.. if you make a change to something using a Windows app, while the file is open in something in WSL, then WSL cannot see those changes at all? (presumably until all WSL file handles are closed?) Is that how I'm to understand that?

So, there's not a possible way to directly map FindFirstChangeNotification or ReadDirectoryChangesW into inotify ?

commented

Thanks for the clarification @ericblade! In terms of developer workflow, doesn't that effectively lead to the same end result: A web developer working in /mnt/c/web/my_cool_project using their favorite Windows editor/IDE won't trigger the watch processes of the aforementioned build tools (Gulp, Browserify, Webpack, etc.) when they save updates to files?

commented

That's what I'm assuming because one layer isn't talking to the other and vice verse. However, editing with VIM from the terminal will trigger it I'm assuming.

commented

If you use Windows Notepad++ to make changes, we won't be able to report it.

That's a bit of a bummer to hear. It's been an annoying problem with using VM shared folders for a long time now (though I believe Macs can make things work using NFS), I was hoping that WSL would finally come along and help us out. I know from experience that polling workarounds (if they're even available) have quite a few downsides. As it stands, workflow, particularly for web dev, is still going to be seriously hampered on Windows machines without some major pain points in terms of configuring tooling... unless you like to work in Vim.

Edit: here is one of the workarounds for Vagrant, readme has a summary of the general problem. Maybe the WSL team can take inspiration.

commented

I use the Windows versions of most of the stuff that I use, so I'm not especially hampered by this functionality missing, but I did want to see if my operating system builds would work on it, and OpenEmbedded just won't even start up without this functionality. :-)

I'm curious what the behavior is now when you edit a file in a Windows app while you have a handle open in WSL. It seems like having two vastly differing methods of access could potentially cause disturbing results, and I don't just mean you accidentally overwrite some changes you made earlier with changes you just made now, I'm thinking of the catastrophic loss of file type of results. Not that I'm saying it is a thing, but I'd like to know what actually happens, so that we can be aware of it.

commented

Sublimetext for Ubuntu works great inside WSL. Just launch it with an X server like VcXsrv or Xming and it will take advantage of all the new supported features like filesystem watchers.

commented

@ericblade, I have seen issues when using Atom on the windows side, and changing git branches in WSL. Things seem to get confused, and I get into a state where neither side has permissions to a certain directory or file. I haven't nailed down the exact reproduction steps, but it has happened more than once, and is quite a pain to recover from.

commented

I just noticed @onomatopellan's post. That is brilliant! I know what I'll be doing at lunch today.

commented

[edited after I solved the issue to include the errors and the solutions]

I have vcXsrv running and can run xcalc but when I tried installing sublime text:

sudo add-apt-repository ppa:webupd8team/sublime-text-3
sudo apt-get update
sudo apt-get install sublime-text-installer

it gives this error:

cp: cannot create regular file β€˜/usr/share/icons/hicolor/48x48/apps/’: No such file or directory

It does infact installs ok in /opt/sublime_text/, but fails to create links in /usr/local/bin (which, although, can be done manually afterwards with ln -s /opt/sublime_text/sublime_text /usr/local/bin/sublime_text)

But on launching it gives this error:

Unable to load libgdk-x11-2.0.so

It seems I needed to install libgdk and/or xbase-clients and other such basic libraries for GUI support I guess which doesn't come with bare bash.

sudo apt-get install -y xbase-clients libgtk2.0-0 libgdk-pixbuf2.0-0 libfontconfig1 libxrender1 libx11-6 libglib2.0-0  libxft2 libfreetype6 libc6 zlib1g libpng12-0 libstdc++6-4.8-dbg-arm64-cross libgcc1

It might need fewer libs than that but I'm not sure and just being inclusive.

commented

@laggingreflex You shouldn't have problems downloading the tarball:
cd
sudo apt install libgtk2.0-0
wget https://download.sublimetext.com/sublime_text_3_build_3114_x64.tar.bz2
tar xvjf sublime_text_3_build_3114_x64.tar.bz2
DISPLAY=:0.0 ./sublime_text_3/sublime_text

commented

@jwsloan

I have seen issues when using Atom on the windows side, and changing git branches in WSL. Things seem to get confused, and I get into a state where neither side has permissions to a certain directory or file.

Yeah.. I'm afraid that actually being able to directly access /mnt/c and such might actually be a really bad idea. Perhaps it might be a good idea to actually yank that file system layer, and replace it with NFS or something. It sounds like it's going to lead people into nasty problems.

commented

though I believe Macs can make things work using NFS - @noinkling

Not sure about NFS, but for anyone who doesn't also use a Mac: yes, on OSX you can go between the CLI and GUI without any serious hitches. Changes can be triggered on both sides, although it remains a bad idea to edit the same file in two different editors (that's just confusing :)).

commented

I was able to install submlime-text-3 using the steps that failed for @laggingreflex. Then I used the following so that I can run subl some_file.rb to launch it.
ln -s /opt/sublime_text/sublime_text /usr/local/bin/subl

commented

Update from build 14915:

Goal
Launch fresh Rails 5 app

Commands
rails new wsl-notify-test
cd wsl-notify-test
rails server

Result

/root/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/watcher.rb:74:in `initialize': Invalid argument - Failed to watch "/root/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/activesupport-5.0.0.1/lib/active_support/locale": the given event mask contains no legal events; or fd is not an inotify file descriptor. (Errno::EINVAL)

Workaround
When creating the app:
rails new wsl-notify-test --skip-listen

commented

Hi all.. can I ask a basic question. Does WSL always get updated with the insiders build, or is that something that is done independently? Where can we reliably look to see what was pushed down to WSL? thx

commented

@alanosman @jwsloan
Yes, WSL gets updated with the insiders build:
https://msdn.microsoft.com/en-us/commandline/wsl/release_notes
Inotify for WSL-generated events did not make this insider build (14915), should be in the near future.

commented

Thanks @jwsloan - am excited to get Inotify working! So close.

commented

Thanks, @JasonLinMS. I saw those release notes as well, and mistook the socket related stuff for notify related stuff. Oh well. Those updates did fix my spring issue. If I --skip-listen and use guard -p, I get my spring + guard TDD workflow back! Woohoo!

commented

@jwsloan That's great to hear, thanks for using WSL!

commented

Is there any ETA on this i.e. are we talking weeks, months or years. I was so excited to learn that the Bash console was a thing I hastily uninstalled Node.JS and Ruby for Windows and now I'm completely hampered by lack of a SASS watch task and ENOMEM in my 8GB machine.

Should I revert my workflow or is this imminent?

commented

@jamieburchell you do know that SASS can poll right?

commented

@envygeeks That looks promising, thanks for the tip!
EDIT: This only works with Grunt < 1.0.0 because of:
Warning: grunt.util._.chain(...).pluck is not a function Use --force to continue.

commented

Webpack is still having the issue too and I don't know of any workaround? It was mentioned the Anniversary Update release would fix Inotify but it appears to still be an issue.

commented

@mastrauckas I don't believe we ever committed to inotify would be implemented in time for the Anniversary Update (correct me if I'm wrong). However it has been implemented and will be in a Windows Insider build soon.

commented

@benhillis That is my fault. I thought it was said it would be in the Anniversary Update when it was said it would not be fully supported in the Anniversary update.

Once it's fully supported, and i'm running webpack --watch to transcompile script.js and I make changes usingVS Code(Which is a Windows application since I can't run UI version of Linux applications on Bash for Windows), will webpack be notified of those changes?

commented

@mastrauckas Install VcXSrv, no problem in running UI version at all.

commented

@SRGOM -- cool; glad that works! Hopefully that will get people un-stuck.

@SRGOM @benhillis -- this particular issue isn't the most important to me personally (that honor is shared between #468 and #616 at the moment), but hopefully I'm not distracting too much from those issues by making sure you're aware of the following potential incongruity:

  • I believe it has been stated elsewhere that WSL inotify support will not (?) fire a notification when a file is changed from Windows
  • WSL does not officially support graphical Linux applications. WSL users have been encouraged to use Windows graphical editors and DrvFs.

My impression, which may be incorrect, is that the majority of requests for inotify support have been people (often NodeJS users) who want their app to auto-reload when they make changes in an editor. I'd love to have Linux-only inotify; I've written some cool shell hacks with it in the past :-) But in the context of the UserVoice and the GitHub bugtracker, I'm not sure I understand the user story for it?

commented

@aseering inotify support is being added in two phases:

  1. Generic support for inotify and inotify for changes coming from within WSL (other Linux processes) is implemented and making its way to Windows Insider builds.
  2. Inotify support notifications for changes coming from non-Linux processes (DriveFs files changed from Windows processes). This change is being worked on now by one of our developers.

Hope that clears things up.

commented

That is great to hear, @benhillis! I really appreciate the clarification. This a great example of why this repo is awesome. I love the responsiveness.

commented

@benhillis that sounds great. Do you have an ETA when phase two will get pushed to the insiders? Because phase one is a huge limitation that I would think would effect majority of people.

commented

@mastrauckas For Phase 2, the feature is currently being worked on. I would estimate that it would reach insiders before or around mid-October, and we can also provide updates on the timeline as time passes.
One thing to note about Phase 2 regarding inotify for DriveFs files changed from Windows is that we are relying on an internal API similar to the user-mode ReadDirectoryChangesW, so we cannot return all 12 Linux inotify events. Events such as IN_OPEN and IN_ACCESS will never be reported, since NT cannot return the equivalent events. Events for delete, rename (though no rename cookie) and modify can be reported, so hopefully that will be enough to cover most of the scenarios.

commented

@JasonLinMS thanks for the information.

commented

I suspect that as long as the APIs do not fail, I will be happy just to have them running. I'm not particularly sure exactly why OpenEmbedded refuses to even start without inotify support, but it currently does. I'm sure I could find out quickly, if I wanted to spend the time to discover, but I don't have that time :-D

commented

@JasonLinMS I am so psyched to hear that "Phase 2" will be complete before year end! To be frank, if it works as advertised, that will be the final brick in the wall regarding my ability to recommend Windows 10 to web developers who, up until this point, have been fiercely loyal to OS X. While my personal workstation is a Windows 10 PC now (loving it, totally happy to be back in control of my hardware), I retain an Apple laptop with OS X for my professional web development work. I'm really curious to see how the landscape changes over the next year!

Thanks to everyone on the WSL team for their continued work in this area. 🍻

commented

@awkaiser Very glad to hear this, thanks for the encouragement. We believe Phase 2 will work as advertised for web development scenarios, and if it doesn't, let us know after it comes out.

commented

@patryk9200 Yep, it appears to be phase one.

commented

I am so psyched to hear that "Phase 2" will be complete before year end! To be frank, if it works as advertised, that will be the final brick in the wall regarding my ability to recommend Windows 10 to web developers who, up until this point, have been fiercely loyal to OS X.

I completely agree. Making it possible to edit files in VSCode for Windows and run development tools (in my case ember-cli) in WSL is all that's missing for me right now to enthusiastically recommend Windows 10 and WSL to skeptical OSX-using colleagues πŸ˜„

commented

F.Y.I.: 14926 build, Gulp Watch works flawlessly with Visual Studio Code . Now I can write code in windows and run auto test in WSL. πŸ‘

commented

@wycats this is also required for ember-cli to work. #468.

commented

@merlinvn did you run Visual Studio Code from inside the WSL to make gulp watch work, or did you run it from Windows natively? There's a difference, considering this comment by @benhillis.

Is there any estimate for hitting the Release Candidate Build? I'm not on the Fast/Slow ring.

commented

@wizardist, I run VS Code in windows, and run gulp watch inside WSL. Watch cannot run in the previous build.

commented

@merlinvn Hmm, that's surprising! Doesn't Gulp's watch rely on Gaze, which defaults to "auto" mode, watching for changes via native OS events or polling? With the "Phase 1" inotify fixes, I'd expect Gaze to choose native OS events and not bother with polling. Since the WSL team hasn't announced availability of "Phase 2" fixes, is it possible that you're experiencing a fall back to polling (either automatically or because your project config enables polling)?

If the watch process is working "out of the box" with native OS events in the WSL context, with WSL files modified by a Windows application, I'm mighty confused about what has been communicated to us so far... πŸ˜–

commented

@awkaiser It surprised me too. In the release note for 14926, it is stated that modified file in windows does not generate any event. However, it is what it shows in the screenshot.
screenshot 12

commented

@merlinvn Inotify currently does not generate any events from changes made in Windows. What you are seeing is strange. Can you try modifying the code file from notepad.exe? You should see that no events are detected in bash.exe....

commented

@JasonLinMS ... Notepad works as showed in the screenshot...

screenshot 17

commented

@merlinvn In that case, the only explanation would be that Gulp must be using polling underneath, perhaps like what "tail -f" is doing.

commented

@JasonLinMS It could be... But, I cannot run gulp watch until this 14926 build.

commented

Can you share your Gulpfile so we can investigate further?

On Sun, Sep 18, 2016, 02:37 Nguyen Tran notifications@github.com wrote:

@JasonLinMS https://github.com/JasonLinMS It could be... But, I cannot
run gulp watch until this 14926 build.

β€”
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#216 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABT29C87WS4OgJ9TrJM4Yg58FfvAZMDyks5qrIfJgaJpZM4IJBcu
.

commented

Wow, that does indeed look like it's working as intended. Maybe watch does
some sort of fallback now?

Are you using the builtin version of gulp-watch right?

On Sun, Sep 18, 2016, 10:48 Nguyen Tran notifications@github.com wrote:

I@kokarn: Here is my gulp.js file
https://gist.github.com/merlinvn/9c4cbd4e827591332ffc8bc58eaae863
http://url

β€”
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#216 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABT29CjtG6Is_y_a2Ae_hu_czplSDzS8ks5qrPrUgaJpZM4IJBcu
.

commented

I only install the latest gulp-cli as global and gulp for the local
project, if it is what you are asking about version.

On Sep 18, 2016 3:53 PM, "Oskar Risberg" notifications@github.com wrote:

Wow, that does indeed look like it's working as intended. Maybe watch does
some sort of fallback now?

Are you using the builtin version of gulp-watch right?

On Sun, Sep 18, 2016, 10:48 Nguyen Tran notifications@github.com wrote:

I@kokarn: Here is my gulp.js file
https://gist.github.com/merlinvn/9c4cbd4e827591332ffc8bc58eaae863
http://url

β€”
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#216
issuecomment-247835204>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ABT29CjtG6Is_y_a2Ae_hu_czplSDzS8ks5qrPrUgaJpZM4IJBcu>
.

β€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#216 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdNy8vEJHVJRqdEBNqSc-P87OAz7XUgks5qrPwcgaJpZM4IJBcu
.

commented

@awkaiser I went ahead and checked with angular-cli again just to be sure, and you interpreted the message right, don't worry. It doesn't work yet when files edited under Windows, but it does work like how @benhillis said before (phase 1).

commented

guard now works without -p! Woohoo!

I'm probably just going to keep using ST from within WSL until phase 2 is complete. There does seem to be some issue when stopping guard, but it hasn't really caused me any issues.

$ guard
20:15:38 - INFO - Guard::Minitest 2.4.6 is running, with Minitest::Unit 5.9.0!
20:15:38 - INFO - Guard::Spring starting Spring
Running via Spring preloader in process 7379
Running via Spring preloader in process 7393
20:16:19 - INFO - Guard is now watching at '/root/Projects/myProject'
[1] guard(main)> exit
20:16:22 - INFO - Guard::Spring stopping Spring
Spring stopped.
E, [2016-09-18T20:16:24.983508 #7370] ERROR -- : run() in thread failed: undefined method `callback!' for nil:NilClass:\n /root/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/event.rb:128:in `callback!'
commented

I'm not an expert in Ruby, but perhaps it's related to this?

guard/rb-inotify@a3ff7cc

From: John Sloan notifications@github.com
Sent: Sunday, September 18, 2016 6:23:37 PM
To: Microsoft/BashOnWindows
Cc: Jason Lin; Mention
Subject: Re: [Microsoft/BashOnWindows] Filesystem watchers like libinotify do not work (#216)

guard now works without -p! Woohoo!

I'm probably just going to keep using ST from within WSL until phase 2 is complete. There does seem to be some issue when stopping guard, but it hasn't really caused me any issues.

$ guard
20:15:38 - INFO - Guard::Minitest 2.4.6 is running, with Minitest::Unit 5.9.0!
20:15:38 - INFO - Guard::Spring starting Spring
Running via Spring preloader in process 7379
Running via Spring preloader in process 7393
20:16:19 - INFO - Guard is now watching at '/root/Projects/myProject'
[1] guard(main)> exit
20:16:22 - INFO - Guard::Spring stopping Spring
Spring stopped.
E, [2016-09-18T20:16:24.983508 #7370] ERROR -- : run() in thread failed: undefined method callback!' for nil:NilClass:\n /root/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/event.rb:128:incallback!'

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/216#issuecomment-247896994, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKq71bU-Qpl7WSG4X8up0bsetz3gx-qMks5qreQZgaJpZM4IJBcu.

commented

Good call, @JasonLinMS. I didn't even think to go check out the source.

commented

INOTIFY from DrvFS should now be complete within 14936 - please give it a shot and close if fixed.

commented

Hmm, I'm still not seeing ava --watch refresh when I save in IntelliJ....

commented

@bitcrazed this does not seem to be working for me, either.

Running guard under /mnt/c/Users/me/Projects/MyRailsProject does not detect any changes. This is true of making changes either through a Windows editor or from within WSL.

commented

@bitcrazed Doesn't seem to work, tested with angular-cli (which uses webpack internally). Tried with multiple editors.

commented

I haven't had a chance to try build 14936 myself, but I have two questions for @bitcrazed and rest of team:

  1. When can we expect this great WSL change to land outside of the Windows Insider program?
  2. Will INOTIFY from DrvFS work with existing instances, or is there something that needs to be done to update them? (Hopefully a fresh lxrun.exe /install isn't necessary.)

For everyone reporting that this isn't working, I have to ask, are you 100% certain that you're running the latest Windows Insider build? 14936? πŸ˜• (Kinda bummed to hear all negative reports so far.)

commented

@awkaiser I just installed 14936 to try this out, so yeah, I'm positive I'm on that build. I have not reinstalled the instance, but it wasn't necessary before, so I'm guessing it really doesn't matter. Can do a fresh install though, if you think it's worth a shot.