Symlinks and hardlinks are reported as files on linux

[DanielCodesphere]

Instead of hard_link or sym_link the path_type is always file.

If i do ln -s a b in the watched directory i get create file b and no associatedPathName.

I am most likely using inotify, but i don't know if there is a way to tell for sure.
Maybe the watcher could say that in the self/live event?

[e-dant]

Maybe the watcher could say that in the self/live event?

I've been hesitant to add that because the primary use is debugging (IOW, I'm hesitant to add any debugging stuff to actually released code). But this has come up before, so maybe we should add it.

There are times it's probably useful.

It is especially useful to know how the watcher selects a filesystem even subsystem a-priori (and we document that in the Platform-specific adapter selection subsection). It's a bit hidden, admittedly.

The reason it might be useful to know that before the watcher runs is because of file descriptor limitations on inotify. If someone wants to change that, they should also know if the watcher will use inotify.

Although, which filesystem event subsystem is in use at runtime is probably useful for checking that the watcher is doing with what it is expected to do. And maybe that's not solely debugging.

Instead of hard_link or sym_link the path_type is always file.

I am still investigating the best solution, and I have not forgotten about this.

[DanielCodesphere]

Is the associatedPathName of a symlink supposed to be the target?
If so what should happen when a symlink is renamed?
In that case would the associatedPathName be the rename destination or the symlink target?

[e-dant]

Is the associatedPathName of a symlink supposed to be the target?

Yes