Closed mitchellwrosen closed 6 years ago
Are there any workarounds available?
You may be able to filter these files out (not use const True
).
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.
@Prillan Did you mean const False
instead of const True
?
@mitchellwrosen Yes, of course. I tested both and copied the wrong one. I've edited my previous post.
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?
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?)
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 causewatchTree
& friends to throw an exception: