Not stable against Dir.chdir; how to work around?

[akerbos]

Consider this code:

require 'rubygems'
require 'listen'

callback = Proc.new do |modified, added, removed|
  puts "m $#{modified.join(" ")}"
  puts "a $#{added.join(" ")}"
  puts "r $#{removed.join(" ")}"
end

@listener = Listen.to('.').ignore('sub').change(&callback)      
@listener.start(false)

Dir.chdir('sub')
sleep()

Apparently, listen works with relative paths internally, which causes a) remove events for all files in the main directory after the chdir and b) events inside of sub to be reported after chdir (despite the ignore).

Using chdir with blocks, i.e.

Dir.chdir('sub') do 
  sleep()
end

does not help.

I suggest that listen should use total paths internally to be stable against this. If there are hard reasons against that, how can one circumvent the issue (short of not using chdir)?

[Maher4Ever]

A simple fix for your problem would be to pass Dir.pwd as an argument to Listen.to. It would indeed be better to convert the passed path into an absolute path to avoid this kind of problems in the future. Thanks for the report.

[Maher4Ever]

Could you try the fix and see it it helps with your case?

[akerbos]

Now no change events seem to get through.

[Maher4Ever]

I just pushed a fix for the problem caused by the the previous one. Everything inside Listen now will be working with absolute paths to avoid the problems caused by changing the Dir.pwd of the process. Hopefully your example will work now as you would expect it to :)

[akerbos]

Thanks! It works as expected in the simple case from above; when I edit files in the ignored subdirectory, those events are filtered.

However, when I modify a deeper file, say ./sub/sub2/test in above example, modified events are thrown.

Also, when I navigate into the ignored subdirectory's subdirectories with Nautilus, added events are thrown for those files that are viewed for the first time! Note that this does not happen for watched (sub)+directories. Weird?

[Maher4Ever]

Changes inside directories which are inside an ignored path does get reported, which should not happen! I'll investigate this and respond to you shortly. Thanks for reporting this weird bug :)