Guard no longer detecting file changes with Yosemite OSX 10.10 - ruby-on-rails

Question

I set up a clean install of Yosemite and can't get guard to detect whenever a file is changed.
My Environment:
guard (2.6.1)
guard-minitest (2.2.0)
rubygems-bundler (1.4.4)
Ruby 1.9.3 and 2.0.0 both have been testing
Here is the output from debugging:
tom#Toms-MBP:~/Sites/tick (master)$ LISTEN_GEM_DEBUGGING=2 bundle exec guard -d
I, [2014-10-27T15:34:53.417196 #1059] INFO -- : Celluloid loglevel set to: 0
15:34:53 - DEBUG - Command execution: emacsclient --eval '1' 2> /dev/null || echo 'N/A'
15:34:53 - INFO - Guard is using TerminalTitle to send notifications.
15:34:53 - DEBUG - Command execution: hash stty
15:34:53 - DEBUG - Guard starts all plugins
15:34:53 - DEBUG - Hook :start_begin executed for Guard::Minitest
15:34:53 - INFO - Guard::Minitest 2.3.2 is running, with Minitest::Unit 4.7.5!
15:34:53 - DEBUG - Hook :start_end executed for Guard::Minitest
15:34:53 - INFO - Guard is now watching at '/Users/tom/Dropbox/Sites/tick'
15:34:53 - DEBUG - Command execution: sysctl -n hw.ncpu
D, [2014-10-27T15:34:53.517668 #1059] DEBUG -- : Adapter: considering TCP ...
D, [2014-10-27T15:34:53.517749 #1059] DEBUG -- : Adapter: considering polling ...
D, [2014-10-27T15:34:53.517776 #1059] DEBUG -- : Adapter: considering optimized backend...
I, [2014-10-27T15:34:53.587089 #1059] INFO -- : Record.build(): 0.06837701797485352 seconds
15:34:53 - DEBUG - Command execution: stty -g 2>/dev/null
15:34:53 - DEBUG - Start interactor
[1] guard(main)>
I am not sure how to test the underlying listen gem, but seems like it has to be related. I have confirmed that guard works correctly with polling (bundle exec guard start --force-polling).

Answer 1

I was able to resolve my issue by moving the files out of Dropbox. Once I saw this working, I knew that Dropbox was somehow causing the issue with the file system. I resolved it by removing the folder and re-adding it through Dropbox and now everything is working as before.

Answer 2

I had the same problem, and only thanks to a warning issued by the LiveReload application I fixed it.
Because the problem is not restrained to Dropbox and/or ruby on rails, I wanted to share what I did:
Rename problematic folder (in my case containing the Guardfile)
Create new folder with the old folders name
Move files from old to new folder
Other solutions mentioned by LiveReload are:
rebooting the computer
checking the disk and repairing permissions via Disk Utility
adding the folder to Spotlight privacy list (the list of folders to not index), and then removing from it, effectively forcing a
reindexing
renaming the folder, and then possibly renaming it back
re-creating the folder and moving the old contents back into it
Read more: http://feedback.livereload.com/knowledgebase/articles/86239
This not only fixed my Guard problem, but also allowed Compass watch to run again.

Answer 3

Did you add rb-fsevent gem ?
group :development, :test do
gem 'rb-fsevent' if `uname` =~ /Darwin/
end
if you're using OS X, it will be used OS X FSEvents API.