Listen 0.4.3 crashes when emacs lock files disappear

[textgoeshere]

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.

[rymai]

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?

[thibaudgg]

Yeah, good idea. I'll do that.

[thibaudgg]

Done in version 0.4.5

[atuleu]

@thibaudgg Thank you, it seems to works perfectly fine now !

[pjammer]

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.

[dkubb]

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.

[thibaudgg]

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

[dkubb]

@thibaudgg Ok, I've sent pull request #45 that fixes the problem I saw.

[thibaudgg]

Released 0.4.6. Thanks!