Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for symlinked directories #19

Closed
hugobarauna opened this issue Aug 10, 2011 · 3 comments
Closed

Support for symlinked directories #19

hugobarauna opened this issue Aug 10, 2011 · 3 comments

Comments

@hugobarauna
Copy link

Imagine the following directories structure:

/home
  --/projects
       --/dir_a
           -- symlink_to_dir_b
       --/dir_b
           -- dir_b_file

If I do:

fsevent.watch "/home/projects/dir_a" do |directories|
  puts "Detected change inside: #{directories.inspect}"
end

And I change the /home/projects/dir_b/dir_b_file, isn't a callback supposed to run?

@ttilley
Copy link
Member

ttilley commented Aug 10, 2011

The symlink itself is a file that hasn't changed, so no. I realize this can be counter-intuitive from an interface standpoint... You could also watch the projects directory itself.

An additional tricky detail is that the fsevents api resolves all paths internally. So if you tried to directly watch /home/projects/dir_a/symlink_to_dir_b you would receive events with paths of the form /home/projects/dir_b... which would break any code expecting the event path to be similar to the one passed in to watch. You could be clever and fully resolve the path yourself before passing it in to watch, but macos also tries to be clever and pretend any path that links into /private/ is a real directory instead of a symlink... So standard unix APIs will resolve /tmp to /private/tmp while mac APIs will simply resolve it to /tmp. I've hit this behavior multiple times in FSSM (yes, having fixed and re-broken it), so I share your headache.

In short, this is confusing but "correct".

@ttilley
Copy link
Member

ttilley commented Aug 11, 2011

...I could see outputting a warning in scenarios like this as a potentially good idea, but I don't think that rb-fsevent would be the right place to put such a warning. It seems like it would make more sense one level up, in an application or library that makes use of rb-fsevent and potentially other backends (like rb-inotify) that would have the same issue. This is especially true given that a polling based backend could potentially see the symlink as a directory and behave exactly how you would have expected.

Is it acceptable to close this issue? If you have any ideas on how to make these "works with polling" style bugs less frustrating I'd love to hear them and keep this ticket open.

@ttilley ttilley closed this as completed Aug 12, 2011
@mpj
Copy link

mpj commented Oct 16, 2012

How would I work around this issue? I have a local development environment with various symlinked directories that I'd like to monitor for changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants