Skip to content

Listen 0.4.3 crashes when emacs lock files disappear #39

Closed
textgoeshere opened this Issue Jun 7, 2012 · 9 comments

6 participants

@textgoeshere
Guard member

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.

@thibaudgg thibaudgg pushed a commit that closed this issue Jun 8, 2012
Thibaud Guillaume-Gentil Fix #39 14c2e4e
@thibaudgg thibaudgg closed this in 14c2e4e Jun 8, 2012
@rymai
Guard member
rymai commented Jun 13, 2012

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?

@rymai rymai reopened this Jun 13, 2012
@thibaudgg
Guard member

Yeah, good idea. I'll do that.

@thibaudgg
Guard member

Done in version 0.4.5

@thibaudgg thibaudgg closed this Jun 13, 2012
@atuleu
atuleu commented Jun 14, 2012

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

@pjammer
pjammer commented Jun 17, 2012

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
dkubb commented Jun 19, 2012

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
Guard member

@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
dkubb commented Jun 19, 2012

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

@thibaudgg
Guard member

Released 0.4.6. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.