When I save a change in emacs 24, listen 0.4.3 crashes with the following backtrace:
> /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:316:in `mtime': No such file or directory - /home/dave/dev/waldorf/spec/models/.#some_spec.rb (Errno::ENOENT)
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:316:in `mtime_of'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:295:in `insert_path'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:243:in `block in detect_additions'
from /home/dave/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/find.rb:41:in `block in find'
from /home/dave/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/find.rb:40:in `catch'
from /home/dave/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/find.rb:40:in `find'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:228:in `detect_additions'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:152:in `block in fetch_changes'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:149:in `each'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/directory_record.rb:149:in `fetch_changes'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/listener.rb:186:in `on_change'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/listener.rb:199:in `block in initialize_adapter'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/adapter.rb:162:in `call'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/adapter.rb:162:in `poll_changed_dirs'
from /home/dave/.rvm/gems/ruby-1.9.3-p194@waldorf/gems/listen-0.4.3/lib/listen/adapters/linux.rb:44:in `block in start'
This doesn't happen with listen 0.4.2. Looking at 89b630f...master it looks like something introduced in the dynamic-detection of mtime. I guess a similar crash will happen with any very short-lived file.
Current workaround is to revert to listen 0.4.2 or configure listen to ignore lock files.
I think we should actually rescue Errno::ENOENT in Listen::DirectoryRecord#insert_path(path) and do nothing so no metadata is added to @paths in such case.
What do you think @thibaudgg, @Maher4Ever?
Yeah, good idea. I'll do that.
Done in version 0.4.5
@thibaudgg Thank you, it seems to works perfectly fine now !
thanks! i had to bundle update listen to get it to load with the latest guard. just for the googles. I'm sure it's irrelevant in the upcoming days.
bundle update listen
I'm seeing the same problem with vim .swp files even with the 0.4.5 release.
There's a race condition where the file existence check is performed in #detect_modifications_and_removals, the mtime is found, and then the file is deleted before #content_modified? executes. The Digest::SHA1.file call blows up and raises an Errno::ENOENT exception.
I fixed the problem locally by rescuing Errno::ENOENT at the end of #content_modified? and returning false. I don't know if that's the best solution but it seems to work in local testing. If you like I can send a pull request, but I wasn't sure how to write a failing spec for this given that it's timing related.
@dkubb yeah I think rescuing Errno::ENOENT is a good solution. You should be able to spec that by mocking Digest::SHA1.file method (and make it raise Errno::ENOENT).
Pull request would be much appreciated, thanks!
@thibaudgg Ok, I've sent pull request #45 that fixes the problem I saw.
Released 0.4.6. Thanks!