Watching parent directories?

[UnkindPartition]

Here's something I want to implement, but I'd like to have some feedback, just in case I'm missing something or there's a better solution.

This is related to #32. Suppose I want to watch a path. As far as I understand, neither Windows nor Linux allow to watch a path. Windows only allows to watch a directory, and Linux allows to watch a file (identified by the inode) but not the path.

So, in either case we'll have to also watch the parent directory.

Now, the immediate parent directory itself may be replaced or even not exist when we start watching. So the question is, should we watch every single directory up the tree?

Here's an example of what I mean. Remember, I'm interested in whatever happens
under a certain path. Let's say it's /foo/bar/baz, and only /foo exists at
the moment. /foo/bar/baz may appear as a result of the following:

mkdir /foo/bar
touch /foo/bar/baz

To catch this, we must first watch for /foo, and after /foo/bar is created,
check and watch for /foo/bar/baz. Moreover, the following may happen later:

rm -rf /foo
mkdir -p /foo/bar
touch /foo/bar/baz

Which means that we must either watch every single directory up the tree, or
readjust the watchlist dynamically if things get deleted/moved (i.e. start
watching / when /foo is deleted, to catch creation of a new /foo).

Am I overcomplicating things here? I feel that watching a path is what the user
usually means, and we should expose a simple and intuitive API, even at the cost
of internal complexity (which is caused by os-level API being too low-level).

[UnkindPartition]

And the second question, should we do the same even when we're watching a directory, not a file?

[gregwebs]

our expectation is that if you are watching /foo/bar/ then bar does exist. I would rather place that constraint on the user API. With the removeWatch capability that is currently unimplemented it would be easy enough to write a function with the existing API that places a watch on /foo/ and when /foo/bar/ is created it removes the watch on /foo/ and creates one on /foo/bar/

We should look into what happens when the directory being watched is deleted and see if that can be reliably detected.

Right now the API exposed is just for watching directories, but yeah when adding file watching we should look into how to handle the file being deleted.

[UnkindPartition]

Ok, I guess it makes sense. So fswatch only provides the portable low-level functionality, and higher-level stuff that can be built on top should go into a separate package, is that right?

[gregwebs]

fswatch can potentially include anything that doesn't bring in dependencies. I am just worried about trying to include complex functionality when there are still issues with the basics. We are actually already exposing multiple APIs: A lower level one with alll the functionality anyone would need (it requires removeWatch) and a higher level one in System.FSNotify.Devel

[thomasjm]

Cleaning up old issues now, I think I'll close this one since there doesn't seem to be a definite proposal. I think the original issue is solved by the recursive watch functions (using watchTree etc. on a folder high enough that it always exists).