> I have a directory in public/ in the rails project directory with
> around 15,000 files in it.  When I fire up guard, the disk gets
> thrashed to the point where the workstation is effectively unusable.
> I *have* added ignore_paths 'public' to the Guardfile, which makes no
> difference.

> Guard works fine with this project on other developers' MacOS
> workstations, this disk-grinding only seems to happen on Linux.

> I have bumped up max_user_watches:

> $ cat /proc/sys/fs/inotify/max_user_watches
> 65536

> I've tried moving the dir containing the 15k files out of the project
> dir, and then symlinking to it; this doesn't fix the problem.

> -----------------------------------------
> Relevant snippet of Gemfile:
> -----------------------------------------
> group :development, :test do
>  gem 'thin'
>  gem 'rspec-rails'
>  gem 'capybara'
>  gem 'fuubar'
>  gem 'nifty-generators'
>  gem 'nokogiri'
>  gem 'sqlite3'
>  gem 'rails_best_practices'
>  gem 'rb-fsevent'
>  gem 'guard-rspec'
> end

> --------------
> Guardfile:
> --------------

> # -*- ruby -
> *-
> # A sample
> Guardfile
> # More info at https://github.com/guard/guard#readme

> ignore_paths 'public'

> # NOTE: spork section needs to come
> first.
> guard 'spork', :rspec_env => { 'RAILS_ENV' => 'test' } do
>  watch('config/application.rb')
>  watch('config/environment.rb')
>  watch(%r{^config/environments/.+\.rb$})
>  watch(%r{^config/initializers/.+\.rb$})
>  watch('Gemfile')
>  watch('Gemfile.lock')
>  watch('spec/factories.rb')
>  watch('spec/spec_helper.rb') { :rspec }
>  watch(%r{^app/(.+)\.rb$})
> end

> guard 'rspec', :version => 2, :cli => "--drb", :all_on_start =>
> false, :all_after_pass => false do
>  watch(%r{^spec/.+_spec\.rb$})
>  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }
>  watch('spec/spec_helper.rb')  { "spec" }

>  # Rails
> example
>  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/
> #{m[1]}_spec.rb" }
>  watch(%r{^app/(.*)(\.erb|\.haml)$})                 { |m| "spec/
> #{m[1]}#{m[2]}_spec.rb" }
>  watch(%r{^app/controllers/(.+)_(controller)\.rb$})  { |m| ["spec/
> routing/#{m[1]}_routing_spec.rb",
>                                                             "spec/
> #{m[2]}s/#{m[1]}_#{m[2]}_spec.rb",
>                                                             "spec/
> acceptance/#{m[1]}_spec.rb"] }
>  watch('spec/factories.rb')                          { "spec" }
>  watch('config/routes.rb')                           { "spec/
> routing" }
>  watch('app/controllers/application_controller.rb')  { "spec/
> controllers" }

>  # Request
> specs
>  watch(%r{^app/views/(.+)/}) { |m| "spec/requests/#{m[1]}
> _request_spec.rb" }
> end

> You can also give a try to Guard 1.1.0.beta that use the Listen gem.

> On May 25, 2012, at 00:34 , eps wrote:

> > I'm using guard with rspec and spork in a on ubuntu 12.04, rails
> > 3.2.3, ruby 1.9.3

> > I have a directory in public/ in the rails project directory with
> > around 15,000 files in it.  When I fire up guard, the disk gets
> > thrashed to the point where the workstation is effectively unusable.
> > I *have* added ignore_paths 'public' to the Guardfile, which makes no
> > difference.

> > Guard works fine with this project on other developers' MacOS
> > workstations, this disk-grinding only seems to happen on Linux.

> > I have bumped up max_user_watches:

> > $ cat /proc/sys/fs/inotify/max_user_watches
> > 65536

> > I've tried moving the dir containing the 15k files out of the project
> > dir, and then symlinking to it; this doesn't fix the problem.

> > -----------------------------------------
> > Relevant snippet of Gemfile:
> > -----------------------------------------
> > group :development, :test do
> >  gem 'thin'
> >  gem 'rspec-rails'
> >  gem 'capybara'
> >  gem 'fuubar'
> >  gem 'nifty-generators'
> >  gem 'nokogiri'
> >  gem 'sqlite3'
> >  gem 'rails_best_practices'
> >  gem 'rb-fsevent'
> >  gem 'guard-rspec'
> > end

> > --------------
> > Guardfile:
> > --------------

> > # -*- ruby -
> > *-
> > # A sample
> > Guardfile
> > # More info athttps://github.com/guard/guard#readme

> > ignore_paths 'public'

> > # NOTE: spork section needs to come
> > first.
> > guard 'spork', :rspec_env => { 'RAILS_ENV' => 'test' } do
> >  watch('config/application.rb')
> >  watch('config/environment.rb')
> >  watch(%r{^config/environments/.+\.rb$})
> >  watch(%r{^config/initializers/.+\.rb$})
> >  watch('Gemfile')
> >  watch('Gemfile.lock')
> >  watch('spec/factories.rb')
> >  watch('spec/spec_helper.rb') { :rspec }
> >  watch(%r{^app/(.+)\.rb$})
> > end

> > guard 'rspec', :version => 2, :cli => "--drb", :all_on_start =>
> > false, :all_after_pass => false do
> >  watch(%r{^spec/.+_spec\.rb$})
> >  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }
> >  watch('spec/spec_helper.rb')  { "spec" }

> >  # Rails
> > example
> >  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/
> > #{m[1]}_spec.rb" }
> >  watch(%r{^app/(.*)(\.erb|\.haml)$})                 { |m| "spec/
> > #{m[1]}#{m[2]}_spec.rb" }
> >  watch(%r{^app/controllers/(.+)_(controller)\.rb$})  { |m| ["spec/
> > routing/#{m[1]}_routing_spec.rb",
> >                                                             "spec/
> > #{m[2]}s/#{m[1]}_#{m[2]}_spec.rb",
> >                                                             "spec/
> > acceptance/#{m[1]}_spec.rb"] }
> >  watch('spec/factories.rb')                          { "spec" }
> >  watch('config/routes.rb')                           { "spec/
> > routing" }
> >  watch('app/controllers/application_controller.rb')  { "spec/
> > controllers" }

> >  # Request
> > specs
> >  watch(%r{^app/views/(.+)/}) { |m| "spec/requests/#{m[1]}
> > _request_spec.rb" }
> > end

> Moving the dir with the 15k files in it (without symlinking back)
> accomplishes this, but I do need those files in place in the project
> to do development work.  I just don't need (or want) guard to watch
> (or even seek/stat) them for rspec testing.

> I am not experiencing the resource allocation problem ("user limit on
> the total  number of inotify watches was reached") that I encountered
> prior to increasing max_user_watches.

> I thought ignore_paths would do what I want, but it doesn't seem to
> help.

> On May 25, 12:11 am, Thibaud Guillaume-Gentil <thib...@thibaud.me>
> wrote:
>> Maybe 65536 isn't enough, we have a good wiki page about that:https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify...

>> You can also give a try to Guard 1.1.0.beta that use the Listen gem.

>> On May 25, 2012, at 00:34 , eps wrote:

>>> I'm using guard with rspec and spork in a on ubuntu 12.04, rails
>>> 3.2.3, ruby 1.9.3

>>> I have a directory in public/ in the rails project directory with
>>> around 15,000 files in it.  When I fire up guard, the disk gets
>>> thrashed to the point where the workstation is effectively unusable.
>>> I *have* added ignore_paths 'public' to the Guardfile, which makes no
>>> difference.

>>> Guard works fine with this project on other developers' MacOS
>>> workstations, this disk-grinding only seems to happen on Linux.

>>> I have bumped up max_user_watches:

>>> $ cat /proc/sys/fs/inotify/max_user_watches
>>> 65536

>>> I've tried moving the dir containing the 15k files out of the project
>>> dir, and then symlinking to it; this doesn't fix the problem.

>>> -----------------------------------------
>>> Relevant snippet of Gemfile:
>>> -----------------------------------------
>>> group :development, :test do
>>>  gem 'thin'
>>>  gem 'rspec-rails'
>>>  gem 'capybara'
>>>  gem 'fuubar'
>>>  gem 'nifty-generators'
>>>  gem 'nokogiri'
>>>  gem 'sqlite3'
>>>  gem 'rails_best_practices'
>>>  gem 'rb-fsevent'
>>>  gem 'guard-rspec'
>>> end

>>> --------------
>>> Guardfile:
>>> --------------

>>> # -*- ruby -
>>> *-
>>> # A sample
>>> Guardfile
>>> # More info athttps://github.com/guard/guard#readme

>>> ignore_paths 'public'

>>> # NOTE: spork section needs to come
>>> first.
>>> guard 'spork', :rspec_env => { 'RAILS_ENV' => 'test' } do
>>>  watch('config/application.rb')
>>>  watch('config/environment.rb')
>>>  watch(%r{^config/environments/.+\.rb$})
>>>  watch(%r{^config/initializers/.+\.rb$})
>>>  watch('Gemfile')
>>>  watch('Gemfile.lock')
>>>  watch('spec/factories.rb')
>>>  watch('spec/spec_helper.rb') { :rspec }
>>>  watch(%r{^app/(.+)\.rb$})
>>> end

>>> guard 'rspec', :version => 2, :cli => "--drb", :all_on_start =>
>>> false, :all_after_pass => false do
>>>  watch(%r{^spec/.+_spec\.rb$})
>>>  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }
>>>  watch('spec/spec_helper.rb')  { "spec" }

>>>  # Rails
>>> example
>>>  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/
>>> #{m[1]}_spec.rb" }
>>>  watch(%r{^app/(.*)(\.erb|\.haml)$})                 { |m| "spec/
>>> #{m[1]}#{m[2]}_spec.rb" }
>>>  watch(%r{^app/controllers/(.+)_(controller)\.rb$})  { |m| ["spec/
>>> routing/#{m[1]}_routing_spec.rb",
>>>                                                             "spec/
>>> #{m[2]}s/#{m[1]}_#{m[2]}_spec.rb",
>>>                                                             "spec/
>>> acceptance/#{m[1]}_spec.rb"] }
>>>  watch('spec/factories.rb')                          { "spec" }
>>>  watch('config/routes.rb')                           { "spec/
>>> routing" }
>>>  watch('app/controllers/application_controller.rb')  { "spec/
>>> controllers" }

>>>  # Request
>>> specs
>>>  watch(%r{^app/views/(.+)/}) { |m| "spec/requests/#{m[1]}
>>> _request_spec.rb" }
>>> end

> rspec ~> 2.10.0, rails-rspec ~> 2.10.0, guard-rspec ~> 0.7.0

> The workstation is perhaps slightly more responsive while the disk is
> thrashing, but guard is still pounding the heck out of it.

> I've changed:

> ignore_paths 'public'
> to
> ignore 'public'

> but that might not be correct?  Neither one prevents the disk from
> thrashing.  Is there any documentation yet for the new 'ignore' and
> 'filter' methods mentioned in the ignore_paths deprecation warning?

> On Fri, May 25, 2012 at 10:41 AM, eps <edsloc...@gmail.com> wrote:
> I have upgraded to 1.1.0-beta and I am seeing the same runaway disk-
> access behavior.

> rspec ~> 2.10.0, rails-rspec ~> 2.10.0, guard-rspec ~> 0.7.0

> The workstation is perhaps slightly more responsive while the disk is
> thrashing, but guard is still pounding the heck out of it.

> I've changed:

> ignore_paths 'public'
> to
> ignore 'public'

> but that might not be correct?  Neither one prevents the disk from
> thrashing.  Is there any documentation yet for the new 'ignore' and
> 'filter' methods mentioned in the ignore_paths deprecation warning?

> rspec ~> 2.10.0, rails-rspec ~> 2.10.0, guard-rspec ~> 0.7.0

> The workstation is perhaps slightly more responsive while the disk is
> thrashing, but guard is still pounding the heck out of it.

> I've changed:

> ignore_paths 'public'
> to
> ignore 'public'

> but that might not be correct?  Neither one prevents the disk from
> thrashing.  Is there any documentation yet for the new 'ignore' and
> 'filter' methods mentioned in the ignore_paths deprecation warning?

> https://github.com/guard/listen#the-patterns-for-filtering-and-ignori...

> On May 25, 2012, at 19:41 , eps wrote:

> > I have upgraded to 1.1.0-beta and I am seeing the same runaway disk-
> > access behavior.

> > rspec ~> 2.10.0, rails-rspec ~> 2.10.0, guard-rspec ~> 0.7.0

> > The workstation is perhaps slightly more responsive while the disk is
> > thrashing, but guard is still pounding the heck out of it.

> > I've changed:

> > ignore_paths 'public'
> > to
> > ignore 'public'

> > but that might not be correct?  Neither one prevents the disk from
> > thrashing.  Is there any documentation yet for the new 'ignore' and
> > 'filter' methods mentioned in the ignore_paths deprecation warning?

> ignore %r{public/}
> ignore '%r{public/}'
> ignore %r{public}
> ignore %r{.*public.*}

> The Guardfile DSL, of course, does not understand the key-value hash
> syntax one would employ when using the Listen gem directly, so my
> guesses look a little different from the documented syntax.

> Is guard not converting the string it gets from the Guardfile into a
> regex (via eval, presumably)?

> Once I do get basic functionality working, what is the correct way to
> match the project root in the regex?  i.e., should I use
> '%r{^public/}', '%r{^./public/}', '%r{^/home/user/Projects/
> some_project/public}' or...?

> On May 25, 11:40 am, Thibaud Guillaume-Gentil <thib...@thibaud.me>
> wrote:
>> the ignore method is the same that Listen gem and you need to provide a regex. ignore 'public' shouldn't work.

>> https://github.com/guard/listen#the-patterns-for-filtering-and-ignori...

>> On May 25, 2012, at 19:41 , eps wrote:

>>> I have upgraded to 1.1.0-beta and I am seeing the same runaway disk-
>>> access behavior.

>>> rspec ~> 2.10.0, rails-rspec ~> 2.10.0, guard-rspec ~> 0.7.0

>>> The workstation is perhaps slightly more responsive while the disk is
>>> thrashing, but guard is still pounding the heck out of it.

>>> I've changed:

>>> ignore_paths 'public'
>>> to
>>> ignore 'public'

>>> but that might not be correct?  Neither one prevents the disk from
>>> thrashing.  Is there any documentation yet for the new 'ignore' and
>>> 'filter' methods mentioned in the ignore_paths deprecation warning?