InotifyError should have more information as to what happened

[ehudkaldor]

[[sorry, re-raising the issue under my correct user]]

For example, add_watch raises InotifyError if the given file does not exist. It would be useful to get some more information as to what happened (file path, type of error - does not exists, cannot read, etc).

example (in this case the file does not exist):
DEBUG:inotify.adapters:Adding watch: [/tmp/leases.db] Error: unable to open file: ('Call failed (should not be -1): (-1) ERRNO=(0)',)

[Elias481]

My Pull-Request #60 adresses this issue at least partly. It fixes forwarding of Error-Number raised by inotify library within Exception and also adds the string-form of that error code to the exception message.
For example on my Centos 7 system the following cases should be reported for add_watch:

EACCES Read access to the given file is not permitted.
EBADF The given file descriptor is not valid.
EFAULT pathname points outside of the process's accessible address space.
EINVAL The given event mask contains no valid events; or fd is not an inotify file descriptor.
ENOENT A directory component in pathname does not exist or is a dangling symbolic link.
ENOMEM Insufficient kernel memory was available.
ENOSPC The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource.

So You would see for example whether EACCES or ENOENT is causing the the Exception.

Not sure wether this is all what You want but from my point of view the only thing this library should be responsible for...

[tortured1]

I haven't dug into the particulars of the library code yet, but I did discover that this unhelpful inotify.calls.InotifyError will be thrown from the result checker in some cases when inotify_add_watch is launched and another process is also doing monitoring, AND that other process is hung. It's a bit tricky to reproduce reliably, because the hang is a weird side-effect of daemon threads not terminating correctly.