Broken symlinks break directory watching

[mitchellwrosen]

It seems stat is called on every file in a directory tree prior to much else. If there's a dead symlink somewhere, it'll cause watchTree & friends to throw an exception:

$ ln -s /tmp/foo /tmp/bar

// in ghci
> mgr <- startManager
> watchTree mgr "/tmp" (const True) print
*** Exception: /tmp/bar: getFileStatus: does not exist (No such file or directory)

[neongreen]

Are there any workarounds available?

[gregwebs]

You may be able to filter these files out (not use const True).

[Prillan]

watchTree mgr "/tmp/" (const False) print fails too.

The problem seems to be getDirectoryContentsPath not checking that the files returned from System.Directory.getDirectoryContents exists. As the documentation for getDirectoryContents says

getDirectoryContents dir returns a list of all entries in dir.

This patch fixes the issue by checking if the file exists first https://github.com/Prillan/hfsnotify/commit/09720ff31126910e391ac49c90706bd7fe86e74c .

I haven't run any rigorous tests on it, but it seems to work, and it definitely fixes the problem with broken links.

[mitchellwrosen]

@Prillan Did you mean const False instead of const True?

[Prillan]

@mitchellwrosen Yes, of course. I tested both and copied the wrong one. I've edited my previous post.

[Prillan]

Also note that the library currently doesn't follow symlinks when checking for updates.

Example:

Setup

/tmp$ tree fsnotify-test
fsnotify-test
├── files
│   └── test
└── links
    └── test -> ../files/test

Start the watcher in /tmp/fsnotify-test/links: watchTree mgr "/tmp/fsnotify-test/links/" (const True) print

The following commands illustrate this point

$ cd fsnotify-test/
$ touch files/test
<no output from watcher>
$ echo "ASDF" >> files/test
<no output from watcher>
$ echo "ASDF" >> links/test
<no output from watcher>
$ ln -s files/test links/test2
Added "/tmp/fsnotify-test/links/test2" 2016-08-09 21:09:36.370309 UTC
$ rm files/test
<no output from watcher>
$ rm links/test
Removed "/tmp/fsnotify-test/links/test" 2016-08-09 21:10:05.512831 UTC

Note that the only actions output were the ones affecting the links themselves.

Do you want me to create a separate issue on this?

[thomasjm]

I just hit this issue also, would it be possible to merge @Prillan's patch to fix the broken symlink issue?

In general, adding a catch seems like a good idea so that individual weird files can't cause the whole watchTree call to throw an exception...

(General question, is this repo still actively maintained?)