search

ewollesen / autotest-inotify

Teaches autotest to use inotify (on Linux) instead of filesystem polling.
http://kill-0.com/projects/autotest-inotify
MIT License
18 stars 7 forks source link

Updates only once #2

Closed baruch closed 14 years ago

baruch commented 14 years ago

When I run autospec and change a file it runs the tests again. But any changes afterwards do not cause a retest, it seems like after the first notification no further notifications happen.

ewollesen commented 14 years ago

I can't seem to reproduce this. Could you let me know what version of ruby you're using? Also what version of the autotest gem? Lastly, which Linux kernel version?

malclocke commented 14 years ago

Picks up 2 sets of changes for me, then stops running. This is with a Rails project.

May fork and debug when I get a spare few minutes.

Ubuntu Lucid ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux] Linux 2.6.32 Rubygems 1.3.5 autotest 4.2.10 autotest-rails 4.1.0 autotest-inotify 0.0.2

malclocke commented 14 years ago

Ok, seem to be getting closer. Each file only gets one notify. So if I modify app/model/foo.rb the correct tests run, but if I modify the same file again they don't.

If I then go and modify a different file, that files related tests will be run. If I modify the second file again, nothing happens. And so on.

Also, if I hit CTRL+C, nothing happens. This should trigger a full run of all tests.

It seems that somehow the notifier for each file is being removed from the stack after the first modification is picked up. If I add it again in the callback:

def handle_file_event(event)
  @changed_files[event.absolute_name] = Time.now
  @notifier.watch(event.absolute_name, :modify) do |event|
    handle_file_event(event)
  end
end

Everything except CTRL+C works as expected. However, I'm pretty certain this is not the right solution. It's as if the :oneshot flag (Only send the event once, then shut down the watcher) is being set on the Inotify::Watcher, but according to the docs and looking at the source it shouldn't be.

ewolles, can you clarify that you don't see this behaviour?

malclocke commented 14 years ago

Looking possibly like a bug in rb-inotify, opening an issue over there

ewollesen commented 14 years ago

I'll try and get to verifying this tonight. Thanks for the research. I suspect that if I wasn't seeing the problem before, I will now, as my setup is very similar to yours.

malclocke commented 14 years ago

I think you can close this issue, as I don't think the problem is with autotest-inotify, it's either with rb-inotify or it's a Kernel issue. See http://github.com/nex3/rb-inotify/issues#issue/4

malclocke commented 14 years ago

Ok, I've got to the bottom of this.

It turns out that my editor (vim, and possibly also emacs) overwrites the original file with a new one when writing a change, rather than opening the original file and overwriting it. This means that the original file that inotify was watching gets deleted, and inotify dutifully stops watching that inode.

baruch, which editor are you using?

I will fork and work on a fix for this, as vim and emacs are pretty popular in the Linux world I think autotest-inotify should work with them.

ewollesen commented 14 years ago

Wow, that's quite the bug. Glad you were able to get to the bottom of it.

FWIW, I'm using GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-03-29 on yellow, modified by Debian

baruch commented 14 years ago

I'm using vim as well.

ewollesen commented 14 years ago

I think/hope that the latest patch from hjdivad will have fixed this issue. If you guys get a chance, check it out, and let me know. I'm going to close this issue, please feel free to reopen it, or recreate it if there's still an issue.

Thanks all